I'm giving the site a bit of a makeover and making the look-and-feel identical from page to page. Not messing much with all the tables; they are what they are, and they are
necessary for the efficient display of data. Hopefully the new colour scheme will enhance readability.
It's actually just taking a few minutes per page. Most of the changes are CSS adjustments.
I've taken apart and repaired the main part of our primary sensors; you'll notice we have wind statistics again.
The rain gauge is still out. It might simply be shot batteries; those will have to wait until I'm working again. Not a huge loss; it's nearly winter, and those who know Ottawa
know it doesn't rain here much through the winter months.
We're up and running again, on backup sensors. I'm just getting some of the contrast threshold settings tweaked, and MCOCR is back to capturing at close to 100%. This, by the way,
can be verified by visiting the Diags page and checking the daily and weekly Hits vs. Misses.
In accordance with the loss of three points of data per scan (Wind Bearing, Wind Speed and 5-minute rainfall), each scan now records 7 possible hits, rather than 10. Maximum possible
hits per typical day now 2016.
I've tweaked MCOCR a bit more; the feature set at this point is nearly complete. I would love to add complete value/character management right on the console, but that would require
rewriting the parameters file, which means an intelligent routine that recognizes what data simply to copy over and what data to replace. Not right now. On my agenda for the near
term: cleaning up the extra-sky buttons and code; doing some tweaks to MCH, and getting some work done on my virtual chip. In my spare time, I'm working on three novels: "Space
Pirate," "The Zero Point" and "Alien Base". (The first, I'm fleshing out and giving a thorough proofing; the second, I'm about two chapters in; the third, I'm writing the outline
and planning the chapters.) I'm also writing a couple of scripts for my radio-comedy show. Busy, busy...
-Bill
We've been having bad luck recently. In this latest episode, the weather senosrs have gone down. I've tried diagnosiing and fixing the problem, but to no avail.
We'll switch over to backup sensors in the next couple of days, and that's how it's going to have to be for a while; I'm unemployed again and can't afford a replacement
weather station. So, for the time being, we'll have no wind or precip data, nor any of their derivatives (e.g. Wind Chill).
Well, we've had some server downtime, for the first time in about 4 years. What I at first thought was a corrupted file turned out instead to be
a byte-sized variable trying to hold a word-sized argument. It took the four years for the value in question to get large enough. It just
emphasizes the importance of appropriate variable sizing and limits checking.
Once the bug was fixed, it was only the work of a few minutes to re-feed it the live readings it had missed.
I've overhauled MCOCR and made it much more workable and accurate. First, it now sports a menu bar, with helpful entries that actually work.
Second, you can now 'seed' the precip-to-date recorder with either 0, or the current precip value, to eliminate the persistent-nil that otherwise
haunts a new sensor. Third, there are now fully-working adjustments for the current Location, Value and Character. They are enabled only in
Adjustment Mode (formerly known as "Test Mode"). Fourth, I've reworked the display-current-value routine in Adjustment Mode; it is now quite
responsive. The segment-threshhold tweak from last iteration was just the trick; capture is now all but perfect. I've just a few more tweaks I want
to put into this program, but it'll probably be at a later date; I want to get back to some of the other projects I'd been working on, including
iLog and companion mobile app, a B-Tree unit, a game, a virtual chip, and MCH itself.
I've tweaked MCOCR again, making the vertical scan segments a touch longer. I've also introduced a new 'SegThresh' value to be used
in character definitions, in the .ini file. With SegThresh, you specify a segment number 1-7, and a threshhold value 0-100. That value,
rather than the overall character threshhold value, will determine that particular segment's brightness. This is to allow finer control over
values that often are hard to capture, particularly away from your lighting source where brightness can vary across a character's
width. For example, for some values I get false-positives in the 'bottom' element, but when I adjust the threshhold value downwards, the false-positives
stop and false-negatives creep in, in the the first element. Being able to specify segment threshhold values will eliminate such
results and make the output a little closer to perfect.
I'm pleased to announce that the CTO has once again captured a perfect week's
observations. In between, we had a week with 1 error. So, in the last three
weeks, the data-capture system has recorded 60,480 discrete items of data and
gotten 60,479 of them correct--a 99.9983% accuracy rate. That's nothing to sneeze
at.
We're having some difficulties with the Environment Canada radar images; they changed
their addresses in the HTML. We're currently tweaking an INI file and should have them
restored shortly.
Well, lightning has struck for a second time at the CTO, in terms of a perfect capture week.
As you can see from the image above, "Data-Capture Accuracy" (based on Optical Character Recognition
from the LCD weather display), last week, out of 20,150 discrete weather readings,
all 20,150 were valid.
We had some unanticipated downtime on Tuesday, while Hydro Ottawa did some work nearby.
When I got home from work that day, I went to restart the server. It was dead. I happened to notice
that it wasn't even registering that it was plugged in. Well, it turned out that the power supply was
dead, and because I don't easily throw anything away, I had a spare. Problem solved. *Phew*!
I've updated MCXML to v1.20. The changes affect the long forecast string.
It now supports lows expressed as 'plus somethingorother' or 'zero'. Already supported 'minus'. Also,
if there is a POP (probability of precipitation) value for that forecast
period, a 'POP whatever%.' is added.
Weather forecasts are restored, as you can see. The outage was caused
by the federal government's changeover to the WET4
format (the standard look-and-feel for all government websites).
Basically put: the format change included adding nights. This and
other things, such as slicing-and-dicing high and low temperature and
POP values, rendered the HTML file from which
I grab forecasts elements much less useful. Now, it's true I could have come up
with a way of deciphering it, going HTML tag-by-tag, but I just wasn't interested. I'm working
again and have limited free time.
I did notice, however, that the old XML feed was being provided again.
It was just a couple of days' work to hack up something that
reads the XML file and extracts the various forecasts elements. It
should work until the XML feed disappears again.
It's not quite perfect yet, but getting there fast. (2016-01-26: It's there.)
I need to modify it
to add the low temperature to each day's spiel, and this morning I
noticed it wasn't capturing the forecast; must look at the XML tomorrow
morning, if it happens again.
In keeping with the new naming convention, I've dubbed it "MCXML". After
adding in some niceties as a help screen and command-line parameters to
control log outputs, it stands at version 1.08.
In other news, I've just about solved my daytime contrast problem. In
Canada's (relatively) northern latitudes, the winter sun shines from a
very low angle, typically 20-25 degrees at noontime. That tends to light
up the CTO Data Capture Stage (which changes the contrast of the image
taken). I've taken measures to ameliorate that,
and they're largely working. I've draped dark cloth over a few areas and
tweaked the contrast settings in my OCR-capture program. By damn, I'll
get it to perfection yet! (2016-01-26: pretty much there.)
I'm back to active development. There will be some updates to MCH soon.
