I've adjusted the barometric pressure charts, to show a maximum of 1050 millibars; this in response to the BP this morning reading 1040--the former upper limit of the
charts.
I've had a new idea for the system, and I think it's a good one. I was looking over the pages, and I thought, wouldn't it be handy to have reports on all the months in
the year? Or on any month you chose. And so I'm working on a new feature. It introduces a few new tags, like so:
<@AMEq 2018 1> - Set any references to this month, to mean January 2018.
<@AMEq 2017 2> - Set any references to this month, to mean Feburary 2017.
<@AMEq 2019 3> - Set any references to this month, to mean March 2019.
<@AMEq A 1> - Set any references to this month, to mean January of this year.
<@AMEq P 2> - Set any references to this month, to mean Febuary of last year.
<@AMEq N 3> - Set any references to this month, to mean next March.
On sober second thought, I'll also add the following:
<@AAEq 2014> - Set any references to this year, to mean 2014. This will allow access to stats from any year.
These tags will only affect the page they're embedded in.
By adding an appropriate tag early in the page code, I can make a 'this month' page show data for any month.
Now, this will take a little work, especially where it parses tags for this month, to get the data source right. However, it will be precious little work.
The way I envision this being set up in the CTO pages, is in each yearly summary table, the month references are clickable; that would lead to a page for that month.
Nice and neat; no fuss, no muss.
In other notes, my new air-core cardboard-box loop antenna is working just fine; I'm still tinkering with it to get the tuning range just so. It's a big sucker—
three feet on a side. I made it out of four boxes, bonded together in a (pardon the expression) swastika sort of pattern. (Duct tape, of course...) It does a fair job of
rejecting electrical interference; then again, the signal gain is much greater, which introduces more noise anyway. I'm looking forward to putting it through its paces
in the next few days.
Over years of watching, I've found a temperature discrepancy with the airport's temperature versus Centretown's. I notice that the airport's temperature bottoms out and
begins rising before Centretown's, in the morning. This morning, for example, the temperatures were three degrees apart a couple hours ago. Now, however, the difference is
just 1.7 degrees, and the Dew Point is actually lower in Centertown. I don't have a good theory for this. Post-sunrise, you can chalk it up to inceased insolation at the
airport site, versus Centertown, which remains shaded out for a little while. I can speculate: a dome of warmer air persists above the city at night; towards dawn, the
temperature differential with the surburbs causes a gentle breeze, and the cooler air begins to displace the dome. That's the best I can do for now.
Well, V 4.82 is running nicely; and my changes to wxCondition worked. There'll be more new versions in coming weeks, as I implement some of the ideas I've come up with
lately.
I'm now busily working out the screens for the new version of mcOCR. I'll want for everything to be controlled by the interface, including character sizing and
positioning; so there'll be a fair bit of shifting around, until I get what I want. I'll be cleaning up the program, too, as it sometimes forgets what mode it's in or,
in adjust mode, sometimes forgets to redraw.
I'm pleased to say that I now have all of the data for 2019 pre-loaded: sunrise, sunset, sunlight, moonrise, moonset, moonlight, moon phase. I've added to the data table
in the This Month and Last Month pages, to show sunrise/set and moon phase; and I've added the same sort of table to Next Month, in case you want to check out sunrise/set in
advance.
As mentioned earlier, I'm slowly adding accordions to my pages, to shorten them up. Problem: the accordion state is not preserved across page refreshes. May have to do
something about that.
With any performance gains I get through my drive to speed up page regenerations, I'll add some more locations to be tracked, for a worldwide picture. That'll mean coming
up with some new versions of data-gathering tools; but, then, that's exactly the idea in the first place: the data feeds can change; and the data-gathering programs can change;
but the weather server doesn't have to. I like the idea of adding worldwide locations; it'll get me some experience in dealing with different data formats, and also expand the
range of websites/data sources from which the tools will be able to capture data.
I took a long break from developing StationBase. It was getting into my daily routine; I couldn't stop thinking about it, working on it; and the bugs just kept coming. Now,
I don't mind that kind of obsession in a job--it makes me a better employee--but not for free. I'll get back to it in the next few days; and I believe my To-Do list was fairly
short. In the next few weeks, I'll polish up the program, stamp out any other bugs I can detect, whip up some documentation, and post it for download as a Beta product.
In other news, I'm working on a new hardware project: building a four-foot box loop antenna, for DX'ing. For this, I have to bond four cardboard boxes together, for a framework.
Then I'll wrap about 12 turns of wire and attach a variable capacitor, for tuning. I had a loop back in the 90's, and loved it. The gain and directionality of a loop antenna are
mighty impressive. As my receiver has no antenna input for AM radio, I'll be coupling it passively; i.e. just setting the receiver inside the box. That works surprisingly
well. I've spent many a New Year's Eve DX'ing; on the West Coast, that evening was often clear and cold—good DX'ing weather; here, it's just a convenient pastime while
surviving the evening.
On the home-repair front, I've been active. I recently remounted our doorbell ringer, mounted a curtain on our new balcony door, and ran a wire between the two balcony dividers.
In the summer, that wire holds up a piece of bird netting, that serves two purposes: first, it allows the beans I plant each year to climb; second, it dissuades the cat from leaping
through the balcony rails to an uncomfortable landing a storey below. And—I know you'll appreciate this one—yesterday I got myself a new whiteboard. It's about four
times the size of the one I had; and you can never have enough whiteboard space. ;)
For 2019, I intend to continue to develop MCH, implementing new ideas as I come up with them. I should have StationBase (the first release version, anyway) out the door early in
the New Year; and then I can turn my attention to finishing the compiler and instruction processor for vCPU, my virtual microprocessor emulator. That's been a fun project; it's forced
me to start learning my hexadecimal math tables and to delve back into interrupt handling, exception procesing, two's complement notation (which turns out to be the easiest thing in
the world: you just invert the bits and add one), et cetera. I know there'll be some challenges ahead, but I've been thinking about this program for months to years,
and I've mostly solved all anticipated problems in my head, at this point. The way I've mapped out instructions to codes will make the parsing much easier, too.
With two software projects about to be wrapped up, and more ideas than I have time for implementation, Demmery Software is well-poised for 2019. There'll be no shortage
of things to work on.
Finally, while I no longer consider myself Christian (I was born into the Anglican religion, renounced God around age seven, as soon as I could think for myself, and am
a full-fledged atheist nowadays), I'll wish most of you a merry Xmas, Kwanzaa, Hanukkah, or any other solstice festival, a happy new year (Gregorian or lunar); and a
dignified and solemn Ramadan (sorry, I borrowed that last bit from Krusty the Klown).
Me, I'm spending Xmas with my family. The spouse is going to celebrate a secular Hanukkahmas with her platonic lesbian girlfriend. All's well.
I've got V. 4.82 of the weather server queued up for the Sunday-morning reboot. In this version, any Observations data package may include the prefix -ow in its
filename, like so: CTO-Observations-20181222_1459-ow.txt. The -ow is a flag telling MCH to override any previous observations (from that date and tiem) with any data
found in the packet. In any position, the word 'skip' will tell MCH not to process that item. Precipitation items are ignored.
I've done this partly to repair recently flawed weather observations.
Around 8:45, I noticed that the system hadn't updated Centretown or the Living Room in about an hour. I immediately suspected wxCondition, and as the memorized entry
count was just over 255, I deleted all entries, save for one. To no effect.
I noticed that the donor stats were being updated by wxCondition, so backup-data capture was working okay. I watched for several minutes and noticed that no files were
being submitted from the main feeds (inside and CTO-outside).
Well, it turned out that, in fact, the capture server had lost its network connection. That happens about four times per year. I rebooted it, and the data flowed through.
One catch: I'd deleted
all the earlier data, so we have about an hour's worth of the relative humidity reading 1%. All told, small price to pay. And, once again, a lesson learned: don't go
deleting stuff, willy-nilly, until you understand the problem fully. Update 2018-12-25: I've since repaired the data, using the new override feature.
In other news, I've added to the Next Month page a grid that lists the normals for each day, plus the sunrise and sunset. I'll add it soon-ish to the Airport site,
as well.
Also, as part of an effort to speed up the page-generation process, I'm going to be benchmarking page regens and database lookups, to see where the delay is. It can
take up to 20 seconds to regenerate a complete web site; that's too long.
Jesus, this is a day for updates. In the course of mounting our new doorbell, my netbook came alive again. The two are interrelated; I was using a cheap outlet extender
on the end of the long extension cord, to get power to the vestibule area. The thing was too cheap, apparently, and only one of its outlets worked. Quickly swapped it to
something less primitive. So, now I have the live feed from
our security camera, and the netbook's lid cam, to be upgraded eventually. I'm set.
I've noticed that the local humidity readings are high. The backup sensors sit inside a Stephenson screen, under a small patio table. Unfortunately, the contractors
have so far failed to install new eavestroughing—and so it's very wet. It'll dry out in the spring, and next year (presumably), we'll have eavestroughs.
This morning, I've completed testing of wxCondition 2.0. It vastly improves the program's functionality and utility.
First off, let's establish a little terminology. Readings to be memorized and drawn from are 'Donor Readings.' And readings to be affected are 'Souce Readings.'
So, let's suppose you have a main feed for one of your locations—that's the Source feed. Let's say you have backup sensors reporting as "Alt"—and that's
your Donor feed. With me so far?
Optional paramter -pr O or -pr A means give preference to Original (Source) (Default) or Alternate (Donor)
{InstrStr} format:
Datum Name - two characters (Te, BP, RH, ...)
Separator - neutral character of some type
Instruction - One Character:
M - Replace source value with donor value, if source value missing
U - Replace source value with donor value unconditionally
H - Replace source value with donor value, if donor value higher
L - Replace source value with donor value, if donor value lower
P - Only process according to preferences
Separator - neutral character of some type
At any point, if it replaces a value, it recalculates any related values; i.e. Dew Point, Humidex, Wind Chill Index.
Now, I'm going to deploy this directly into production. I know this goes against everything I've learned; but sometimes, you have to be pragmatic. It'll take too long to test
in my SIT setup. Basically, in four or five days, we'll know if it's working properly; and I'm confident that it will. In the worst-case scenario, we'll be without
Relative Humidity readings for a few thours. So the risk analysis returns minimal.
Incidentally, the incidence of mcOCR capturing backup data has now completed 24 hours of perfect capture.
I'm thinking of revamping the site's web pages to include accordions (they make sections of content appear/disappear); it'll make the longer pages much more navigable.
And a final note: I've given up on the idea of taking this project open source. It's just too complicated, with too many pieces. So it'll remain a one-off wonder, quitely
capturing data and generating web pages over the years. I have other open-source projects to publish. Now, should anyone ever want a copy of the source code, I'll gladly
make it available. Gladly.
I'm pleased to say that 'native' relative-humidity readings are now being captured, every five minutes, thanks to backup sensors. It'll take just a couple minutes to
restore to 'borrowing' Environment Canada's reading, come to that. But that's given me a thought.
At present, I have a program—wxCondition—to capture relative-humidity readings from one set of readings, and restore it to another. I simply switched the
inputs. But I've come up with a much-better idea.
wxCondition at present expects inputs to come from only one source. I can, instead, store readings from multiple sites, and substitute them as I please. For this, I've
got a rewrite of wxCondition planned. Capturing data will be as before, except that the data are stored in a file according to its source. All data will be captured,
in this way. For the substitution phase, you'll be able to specify not only the file to be affected, but also the set of 'donor' readings to draw from; whether to apply
a random-wander factor; and which values should be substituted and under what conditions. For example, you can express a preference for one set of values over another;
and for each data item tracked, you can specify whether to go with the highest of the two values, or the lowest; you can replace one value with the other, either when
it's empty, or always; you can process only according to preference; or you can not process the value at all.
For my purposes, I'll always have the backup sensors running. I'll capture that data, substitute the RH value always, and substitute when something's missing from the
main feed. That should increase the system's already-phenomenal data-capture accuracy and allow automatic fallover during main feed failures.
I've worked out an elegant syntax for this. I'm going to have to schedule some time very soon for this; I've already completed the planning stage.
Here, incidentally, are before-and-after images of a typical capture from the backup sensors. Note how the image is out of focus, with very low contrast. Nonetheless,
mcOCR picks up on it and reports correctly—and, remember, this is with cheap, outdated consumer equipment. Note in the second image, the small purple squares;
they mark the "control" or "calibration" area for each character, guaranteed to be empty. It is against this control area that each segment is tested, to determine
whether it is lit.
Tomorrow marks the first turning point in the march of winter: the earliest sunset of the year. This date varies a little, depending upon your latitude. It's caused by
the Earth's orbital eccentricity; i.e. Earth's orbit is not a perfect circle, but an ellipse. At this time of year, Earth is very near perihelion (see my
article on the subject here)—its closest
approach to the sun for the year—and moving at a little greater than the 'average' orbital speed per day. This is causing both sunrise and sunset to shift
'backwards' (later); with the run rising a little later and setting a little earlier, that has the net effect of making the sunset hit its earliest point ahead of the solstice
(Dec. 21—the longest day of winter), and reinforcing sunrise's march. Sunrise will reach its latest point late this month.
All of this underscores how astronomy is worked into the very fabric of our existence. The fact that the sun 'moves' eastward in the sky, by about a degree per day, means
that the stars turn through one complete rotation every 23 hours, 56 minutes (and 4 seconds, if you must). That is the actual rotation period of the Earth—referred
to astronomically as the "sidereal period." So now you know, just in case it ever comes up in casual conversation.
I was into astronomy by age seven, and my interest has never waned. Lately, I've been delving more into theory—Lorenz transformations, relativistic time dilation,
length contraction, and so on—more mathematics. Good thing I haven't forgotten much of my high-school math (which I finished, incidentally, a year early, because,
y'know, I'm bright).
The next turning point is, of course, the solstice itself, on December 21. After that, there is the latest sunrise of the year, again around late December; and following
that, perihelion, on January 3. And then we set our sights on Spring, which in 2019 begins on March 20.
Another thing you might be noticing this time of year, when sunrise and sunset often coincide with our commute to and from work. Next time you're out, on a clear day, right
around sunrise or sunset (which you can always find for any day of the month, here at CTO), look (IF IT IS SAFE TO DO SO) at the horizon opposite from the point where the
sun has just set, or is
about to rise. Chances are good that you'll see a darker slice of the atmosphere, hugging the horizon. As time goes by, it rises and fades away (or concentrates at the
horizon). You've probably seen it many times, filed it away as "Doesn't affect my life." What you are, in fact, seeing is the Earth's shadow, cutting up through our
atmosphere. Another great Fact to Forget.
Incidentally, that bright, star-like object that rises in the East ahead of the sun, right now? That's Venus—our sister planet. Did you know? Venus' equatorial diameter
is just a few-hundred km smaller than Earth's. At 108-million km, its orbit is about two-thirds as large as Earth's (classifying it as in "inferior" planet—one
whose orbit is inside the Earth's). Venus has a thick, carbon-dioxide atmosphere and a runaway greenhouse effect. In the telescope, Venus is a featureless white ball,
unless specialized filters are used; and even then, only patterns in the clouds are revealed. Radar surveys reveal mountain ranges and curiously flattened volcanoes.
And not a drop of water in sight. Yet another Fact to Forget.
Oh, one more thing. That bright star, now rising late in the evening, in the Southeast, that twinkles madly, and often in colour? That's Sirius—known even in my
lifetime as the Dog Star. (Due to its being the brightest star in the constellation Canis Major--the Great Dog.) Canis Major is one of several companion constellations to
Orion, the Hunter, two others being Taurus (the Bull), featuring the red giant Aldebaran, and Canis Minor (the Lesser Dog), anchored by its bright star, Procyon. Orion
itself is visible late at night, at this time of year, as a large X, with three
stars in the middle (the "Belt"). Below that hang three more stars (the "Dagger"). On a clear night in the country, you can see with the naked eye that one of those stars
is fuzzy. It is, in fact, the Great Orion Nebula (Messier 42, or M42, to starheads like me). You've doubtless seen pictures of it, or of the many cocoon-like dust balls
within, where new stars and planets are forming. It is one of just a handful of objects, that are not stars or planets, that we can see with the naked eye. And with that
thought, I'll let you go for now.
Some ideas from StationBase are beginning to percolate through, such as the idea of performing binary searches on sorted data. That would speed the system up a bit. I'd
like to expand the dataset it tracks, and possibly revamp how it stores data.
I'm running into frustration trying to restore local values for relative humidity. About a year ago, my RH sensor became unreliable; since then, I've been 'borrowing' the
airport's RH value. It's not an ideal solution; usually, the temperature is a little higher downtown, and the RH a little lower. But the total heat energy in the air is
about the same, as witnessed by the dew point, which is usually quite close.
About a week ago, I started testing with backup sensors. The signal can reach the server room, and I've got a little stage set up for the capture. I've got mcOCR set up
and waiting for a feed. The missing element is a
working webcam. For the past week, I've searched high and low, and the only models I can find are upwards of $80! I'm sorry, I'm going to connect it to a computer that's
worth less than the webcam! And so I remain in search. I've learned that The Source's inventory-control system is good for nothing; all kinds of products that are supposedly
in stock in any given store, aren't. Why have a website, with a check-stock capability, if that capability doesn't work?
This morning, I'm going to swallow my pride and visit Wal-Mart. Perhaps they'll have something. I don't even need something new-tech; a .3 MP (that's 640x480) webcam would
do the trick just fine.
So, the long and short of it is that within the coming week I hope to have local readings restored for Relative Humidity.
Another frustration is the number of ideas I have, compared to the amount of time I have to execute them. For example, right now I'm juggling the development of StationBase,
in two editions, and vCPU--the emulated CPU and virtual computer. But in the meantime, I've come up with lots more ideas, which just have to wait around. Most of them are in
the contemplation or planning stage, where occasionally I create or modify planning/engineering documents; and most will continue to be for some time to come. Because at
present, my projects whiteboard's Planned section is becoming rather large:
Weather Server: upgrades to data-handling, storage
wxUpdates: add Password to the data submitted
mcTool: Weather server management system
Atmosphere/weather simulator, V2
Virtual Projects Whiteboard (webapp)
Database and indexing unit for general purposes
Light database application
mcOCR overhaul; kill some bugs; make the program more functional, especially around setup stuff.
A final note: I'm into a lot of stuff. Technically, it's stuff I'm not 'qualified' to do. Who cares? I do it anyway. All my life, I've had a burning monkey curiosity to know
everything, understand everything. Vocationally, I've taken the same approach: never pass up an opportunity to do something new, learn something else. It's the reason why I've
become so good in so many areas: writing/documentation (I have literally hundreds of authoring credits), editing/proofing (I've done it professionally), programming
(did it professionally 30 years ago; doing it professionally now), bookkeeping (I kept the books
professionally for my employer for 20 years, and for another 10 for private clients), admin support (25 years' experience), budgeting, PC and network hardware
installation/servicing (30 years), event planning and management, software testing, light maintenance,
all things radio, medical terminology, basic electronics, cooking, mathematics, kitchen management and meal planning; astronomy, meteorology, data-entry, ichthyology (yes!),
house painting, history, geography, cartography. I could go on. The point is that I've never allowed my
relative lack of an education to interfere with my learning. When I get interested in a new thing, I plunge in headfirst, learn all that I can learn and then devise a
practical application. If I'm given the opportunity to do something I don't know how to do, I bloody well look it up, ask questions, learn how--and fast. I learned that from
my co-workers. Phrases like "Oh... I don't know how to do that, sorry" and "Well, that's not in my job description" are not in my vocbabulary. The answer is: "Yes, I
can—or I can learn how." You don't have to tell me
a thing twice. And my education is continuing--I still soak up information like a sponge. What I'm trying to say is that, just as TPG and Newgate 180 found me invaluable for
my adaptability, so can you--by hiring me.
I credit this all to my father, who was (and still is) a one-man swiss-army knife. He was a steely-eyed sonar man in the navy, for 25 years. I've never seen him hire someone
to do a repair, save for once. He built most of the downstairs of our home in Sooke, BC—to code. When I was
very young, he bought a number of encyclopedias, which I pored through constantly; by age ten, I was trying to compile my own. He always encouraged my exploring and
experimentation, knowing that even though I was doing a lot of weird things, I was, first and foremost, learning. While I was at it, I got really good at distance running and
other personal athletics. That's a whole other story.
Never stopped learning, Dad. Never will. And still doing lots of weird things.
Addendum 2018-12-10:
I've concocted a scheme whereby I'm going to swipe the recently-replaced security camera at the front entrance, and use the old netbook's built-in camera until I can get
a replacement. The Scrounge strikes again!
Addendum 2018-12-15:
Well, a funny chain of events ensued. I got the netbook's lid-cam working, swiped the webcam to upstairs for backup-data capture—and the netbook died. I suspect the power
supply. Gonna be a while before I can replace it. In the meantime, the spouse surprised me with a Wyze security camera—a cheap little thing, but, hey, it's wireless.
Unfortunately, it came with a phone-based webapp—there's no way to access it over the network, or from a Windows or Linux box. There are alternate firmware
implementations out there, which purportedly turn the camera into a regular streaming device. I may be able to do something with that. I find it very convenient to have an image
from the securicam on my home page, and miss it.
Now, before it starts to sound like I'm bad-mouthing the camera, I'm really not. It has much to recommend it; such as the ability to deliver video in up to 1080p resolution.
It has a bit of a fisheye view, which is also handy as hell. Colour and brightness renditions are good, and it functions well both in high-light and low-light environments.
Contrast is sharp, and backlighting compensation is good. It's well-constructed and comes with mounting equipment; pop-out legs and a pan base enable it to be positioned
for an optimal view. It's reliable, and it works when you're out and about. And, even in 360p resolution (the lowest), the image quality is very good, indeed. You can either
listen in, thanks to the built-in micrphone; or transmit your own voice through the built-in speaker. There are motion-detection and alert features, the ability to record to an
SD card; and the capability to record very short clips to the cloud. The camera also has a 'night-vision' mode, which does seem to involve some IR detection. All in all, for
its price, this camera is a tremendous bargain—and you won't hear me saying that often.
That said, what I don't like about it is the need for a phone app to access it. No device should require a phone app for setup and operation, unless it is a phone accessory.
So sayeth I. The other point is that, again, you can't access it without the phone app--something I find needlessly and inexplicably limiting. I don't trust phone apps in the
first place; the amount of privacy invasion and snooping you have to put up with, just for basic functionality, is a crying shame. You're a security-cam app? Then why
do you need access to my pictures and files? That stuff matters, to me—and it should to you, too.
I've released v. 4.80 of the weather server. In this version, if there are multiple Readings (Observations), Statistics or Forecasts files waiting in a location's
Inputs folder, the filenames are then cached and processed chronologically, respecting granularity (specifying how mahy files are to be processed at a time).
This version also fixes a hidden bug. I was tracking latitude, longitude, and their components with smallints (signed bytes). All very well and good, except that longitude
values can reach 180--out of range (a SmallInt can track values through the range -128..+127). Those variables have now been changed to type Integer (signed, two bytes; range
-32768..+32767). I found it during a gedankenexperiment associated with the production
of mcTool, the GUI server-manager tool that I'm now planning/beginning to work on.
I'm releasing v. 4.76 of the weather server, MetCommand-Home. It's due to go into production with the automatic sever reboot this morning. This version adds several features.
First, it is now possible to reload a location's info on the fly, in
case you've edited it. This is accomplished by the new RELOAD-LOC-loccode directive. Second, the templates.ini file now has two additional parameters, automatically added
in by the software, but editable. The first, SaveEveryMinutes, sets the number of minutes between saving the templates.ini file. The second, LastSaved, specifies the date and
time the file was last saved by the system. Finally, on query outputs, MCH now gives the reponse file a temporary name, changing it only when it's completely written. This is
to stop some of the CGI-BIN programs from reading a response file too early.
That's about it. I've been focusing my development efforts this week on StationBase, the Desktop Edition of which is coming along very quickly.
We've had some downtime, from about 18:00 Friday, to 19:15 or so last evening. This was our longest blackout since the Great Blackout of 2003; and, I have to say, it
was quite informative. When it first went out, my comment was "It almost never goes out in Centretown. They'll have it back in no time."
Then reality set in.
We turned on the radio, to get more information. They were talking about a tornado in Durobin, and massive power outages. Very early on, Ottawa Hydro was calling this a
"multi-day event." I relucantly resigned myself to a protracted period of living with no electricity.
Around mid-evening, I got bored, and started hunting around for things to keep one entertained during a blackout. I looked my pretty missus up and down, and thought hard:
what would they have done in the old days?
Answer: I hauled out the (battery-powered) radio and started DX'ing. To understand why, you have to appreciate just how radio-noisy is a modern urban environment. Power-lines
and house wiring, any device with a motor, old-fashioned fluorescent tubes, and an array of wireless devices, routers, other radio devices, range extenders, etc., televisions
and monitors,set-top boxes, bluetooth devices, mobile devices including
phones, all contribute to the noise level. And a tremendous amount of it seems to hit the AM band; on some frequencies, and in some directions, it's an absolute din.
But not during a power outage. In a massive one, you could be kilometres from the nearest radio source. The band was incredibly quiet, though a general faint shush of static to
the north told me that power was somewhere nearby. We'll get back to that. The point is, as any DX'er knows intuitively, during a power outage, the AM band is quiet. So I
started DX'ing.
By morning, I had made several trips around the dial and bagged six new stations (for a single session, after 30 years and 600 stations, six new ones is as rare as diamonds used to be).
I kept going
through the day, and found that I could hear stations I hadn't heard since my glory days of the late-nineties (when I had the Optimus receiver that was second to none, and
the radio-noise floor was far lower). I filled two pages with loggings and will be poring over them for a couple of days, pinning down stations I couldn't identify at the time.
There are many ways to identify a station: listen for local references (ads and phone numbers are great for that); from which direction is the maximum signal coming from;
what kind of content are they playing; what time did you hear them; in which language are they presenting; and so on. The moral: I can almost always find something to keep
myself amused. And, in fact, my detailed logging info brought about, on closer examination, three of those six new stations.
The power came back on around seven-fifteen last evening. We were just about to head out to seek provisions, when the house came back to life. I'm pleased to say that I had
most of the electronics unplugged; and most of them survived. I took my time to make sure that the Internet connection was working, then brought up the server and finally the other
computers. So far, so good.
I did notice a problem whereby I was apparently losing data every 10-15 minutes; not all of the readings were showing up. A check of the log file for mcOCR indicated that all the
output files were being generated; and the Outputs folder was empty. That led me to the /home/public
folder, where incoming observations are held before distribution to the various locations' input folders. I noticed a number of unprocessed observations files. A quick test
told me that the preprocessor was failing on one file, which was in the process of being copied as the power failed. The file was empty. Simple solution: delete the file. Now, the
preprocessor chewed through input files; and three minutes later, I had all my readings.
I am sorry to say that the monitor attached to the local-data capture server appears to have died. This is not the problem that you might think it to be. I have network access
to the command line on that machine. Further, the GUI program that actually captures the data outputs both the data, and the marked-up image file, with the LED segments superimposed;
that makes it dead-easy to tell if the alignment is off. If so, you can simply edit the .ini file, and have the GUI program reload it, right from the command line. So there's no actual
need for a screen on that computer. I will have to cobble together some quickie program to feed a manual precipitation reading in and have it added to an input file. That'll
take about an hour.
I'm about to head back to work on StationBase. I've hard-scheduled a server software upgrade for next Sunday morning; there'll be downtime, but hopefully early in the morning,
and hopefully for not too long. I have a written, checklisted plan, so that everything I need gets backed up and restored.
And an epilogue for this story: our search for provisions ended a single block away, where the corner store, and that block, had been powered the whole time and never experienced
more than a quick power glitch. Normally, that's our story.
As mentioned, I got to thinkering yesterday with the way that MCH reads and processes records. To date, I've always gone for maximum reliability by saving changes to
records almost as soon as they've happened. I added a flag yesterday; it's meaning is simple: do, or do not, save records immediately. If there are multiple input files
available, then records are not saved until the last file has been read. (It respects granularity.)
To test it, I copied several-hundred records into one of the input folders. And, instead of picking them off at about 3-4 per second, it went—snarf!—and
took the pile of them down almost instantly.
There will be a new version of the software this Sunday, probably with a few more fixes and/or features tacked on.
To make the task of administering MCH easier, I'm now in the planning stages for a piece of GUI software that will manage most of the tasks you now have to run on the
command line or with a text editor. This piece of software--for now, code-named mcTool, will let you manage:
Your server status (Start Up or Shut Down)
Your Locations
Your events and anniversaries
The System Properties
User Tags (analogous to simple CSS)
Your system .ini file
Your DST rules (Daylight Savings Time)
This is still only in the planning stage. I have two major software projects underway at the moment, in the two versions of
StationBase.
I've released v. 4.72 of the weather server, MetCommand-Home.
In this version:
I've made sure that no sunlight is recorded during non-daylight hours. If sunlight is reported during those times, it is ignored.
I've added granularity factors for most types of input files. If MCH isn't run for a while, but the data feeds are intact, then input files will begin to build
up. It takes MCH a little time to chew through all of those files; and, to date, it's done it all monolithically at startup, reading in all the input files for one
location; then the next; and finally generating web pages. If there are thousands of input files, it can take a while before your system appears to come to life. I've
changed the process so that for each type of file (statistics, observations, forecasts), MCH will only
process a maximum of so-many files at a time; then it will move on to the next task. Now, pages are updated on-time, even while MCH is still chewing through
data. The granularity is set through three new System Properties:
ReadingsFile_Granularity (default 100)
StatsFile_Granularity (default 10)
ForecastsFile_Granularity (default 10)
I tested it extensively last night; it proceeds round-robin through each file type and location, pausing to regenerate web pages on schedule. It's good.
I found a function that was not returning a value. I found that in actual use, the value was ignored, anyway. Nonetheless, I
fixed it. I mention it only to waste your valuable time.
I have a lingering concern that it takes MCH too much time to process each input file. I've entered an item into my To-Do list, telling myself to look into the matter.
This I shall do, and hopefully some improvement can be found. I'm optimistic, because I built the routines using the 'plush-model' concept; things mostly by-the-book;
one instruction per line; everything broken out into subroutines. I expect that there's room for improvement. I believe, for example, that every input is followed
immediately by saving records, for purposes of integrity. Perhaps a flag could be set for this activity to be suspended until after the group of files has been read.
That would certainly speed things up. Perhaps that flag itself could be controlled by a system property, so that really paranoid operators of the software could
sacrifice speed for increased security (that said, in six years of operation, the software has never crashed, or otherwise lost data, while loading observations).
I've been working on MCH. I've tweaked the Moon Phase calculation routines to give more-useful information, and I've expanded the forecast-terms storage; there are
now a maximum of 65,535 entries possible—that's up from 255. The switch from one byte of storage to one word was surprisingly easy; I changed the types of a few
variables, and tweaked a couple of routines to ensure they returned the proper results. That's now in testing for the weekend.
At present, that's all she wrote for version 4.68. It is slated for Production come the Sunday-morning server reboot. I'll be looking for other fixes and features to
implement between now and then.
I'm giving the website an overhaul; making more use of CSS; making sure pages are displaying properly and are properly formatted; and so on. While I'm at it, I'm also
trying to adjust-out the final errors in data capture. I find that sometimes there's a glitch, where a reading jumps temporarily. I'm identifying these problem points and
applying corrections to MCOCR. They're almost all gone.
Over the next few weeks, I'll be checking the sites page-by-page for errors, problems, and opportunities to simplify the pages using CSS. That'll keep me busy for a little
while. I'm also still actively developing StationBase, which is almost ready for a real beta test.
I've made over the site for our living room. It looks great. I'll make it publicly available soon. I'd hemmed and hawwed over the years, fearing that it could
be used for some sort of surveillance. I've finally concluded that there are other ways of telling if someone's at home, and exposing the living room website
will pose no additional risk.
Just an update; I've added a full set of Moon activities for next year. I'm embarrassed it took me so long to realize they were missing!
Still waiting on the balcony to be rebuilt. There's progress, but it's damned slow. I'm going to have to revise my service-restoration date to October.
I've been applying the oh-so-useful dropdown menu to the Ottawa Airport pages, to replace the old chiclet array. Much neater. I'll next work on the templates for site-lookups, so
we'll once again be using a common look-and-feel. While I'm at it, I'll update the CSS.
I'm also touching up the site, here and there, hopefully to make it more understandable.
Apart from that, the software continues its bullet-proof run. There are a few minor issues that I'm slowly identifying; but no hurry.
I'd noticed lately that the remaining readings being captured locally were fluctuating wildly, or reading nonsense; thus the less-than-optimal capture accuracy rate this week.
Turns out that low batteries were at fault.
The batteries have been replaced in the sensor, and we are now receiving believable readings again.
I offer up the following figures in support of my claims for a very high data-capture rate in mcOCR, the OCR-data-capture program that translates local weather readings into inputs
for MCH. Here's how things have looked in recent weeks:
Week Ending On
Hits
Misses
Apr 1
15560
1
Apr 8
15560
1
Apr 15
15561
0
Apr 22
15561
0
Apr 29
15561
0
Totals
77803
2
Error Rate: 0.003% (3E-5) (0.00003)
That's why I claim an accuracy rate of 99.99%. After five years of tinkering, the program really is that good. And, remember, I'm not using professional-quality equipment.
It's all retail, consumer-grade, and very old. Anyway, you can check my numbers in the shutdown report files--they're there for all to see.
I noticed yesterday morning that I was getting data-capture errors. A quick visual inspection showed that the images returned by the webcam were very dark. I left it go
at first, having learned from long experience that these problems usually are transient.
A quick check a couple hours later showed that the problem was still there. Another visual inspection showed that the spotlight on the data-capture stage was burning out.
Replaced the bulb, and almost end of story.
Just two points to make. First, that it's the first time I've lost a CFL after only about five years. Second: with the system (mcOCR, to be specific) still capturing 60-70%
of the data, in deep
shadow, I was amazed at its performance under low-light conditions.
(Update @ 22:35): Well, it's been a perfect trifecta of downtime over the past couple of days. This afternoon, while vacuuming, my SO bumped the data-capture stage,throwing
the camera out of whack. We lost about an hour's worth of data (half an hour before I noticed, and another half-hour getting the thing realigned and mcOCR's settings adjusted).
Then, just to round things out, this evening someone joggled the network cable to the data-capture server,
putting it out of action for three hours. Luckily, this didn't affect the main system otherwise, and as soon as the network routing had been re-established, the data came
pouring through.
I'm releasing version 4.66d in the morning--it fixes (finally!) the moon-age bug. I couldn't find code that actually worked, so I put my in-depth knowledge of astronomy to
good use (been heavily into it for 45 years and counting) and wrote my own. And it does work.
I've left the system as it is for the past month or so. I'm debugging one routine that doesn't really impact operations.
All told, we've had a pretty normal January here in Centretown. Temperatures have averaged just over half a degree below normal, precipitation has been 45.5 (normal 48.5),
and sunshine is bang-on at 83 hours. Temperature and sunshine should finish more favourably by month's end.
Already the first signs of spring are coming. Sunset, for example, is already a good 40 minutes later than it was at minimum in early December. Sunrise has only come back
by about 15 minutes, thus far; but it's a start—and it doesn't let up until late June.
In the meantime, I'm working on a new project: StationBase. It's a tool aimed at DX'ers (people, like me, who stay up late with a
radio and try to catch long-distance stations), to help them keep their records straight. It handles multiple locations, sets of equipment, station records, and individual
loggings. I'm expecting to start a semi-public (by invitation) beta test by late-February,
or early March.
This time around, the program is a web application, written in Java and designed to interact with the operator in realtime. I've got some screen shots up now. The program
still doesn't have much personality; I'll add that as we progress closer towards beta.
