Category: Software and Firmware

  • Many folks have asked whether screen burn-in, or phosphor burn, is not a problem. They are concerned by what was a frequent occurrence in the CRT monitors and oscilloscopes of yesteryear: a permanent scar prominently visible on the screen…

    Phosphor burn – this old spectrum analyser looks ‘on’ even when it’s off!

    To understand why this occurs, first think of an iron burn. If you deliver too much heat for too long into the same spot, your nice new Oscilloclock brand T-shirt will feature a prominent (and permanent) mark as shown below.

    Iron burn – this shirt’s fibres have been literally scorched!

    (I could push for another analogy, and describe livestock branding – but I think you get the message.)

    In a CRT, a beam of fast-moving electrons bombards the phosphor coating on the screen to produce an image. If the beam is too intense, or it is allowed to trace the same route on the screen over a long period of time, the phosphor compound may degrade and lose its luminance. The end result is:

    • The screen won’t light up well in those spots any longer.
    • The damaged areas may appear dark even with the power off – a ‘ghost image’.

    Interestingly, this damage does not actually shorten the working life of the CRT! (It does not affect the longevity of the heater, or the amount of gas permeating the vacuum.) However, it is certainly not attractive, and is most definitely NOT an effect you wish to observe on your fancy custom-crafted Oscilloclock…

    Keeping the ghosts at bay

    Happily, screen burn-in is not much a problem with the Oscilloclock. Let’s see why.

    1. CRT selection

    Some CRT types and brands are more susceptible to screen burn-in than others. There are a number of factors for this, and all of these are considered during CRT selection to minimize the risk of burn-in:

    First, there is the phosphor compound used. Some phosphors, just by their chemical makeup, degrade faster than others. More significant, though, is the fact that some phosphors require more energy (electron beam intensity) to produce the same level of visible light output as others.

    For example, a long-persistence blue P7 phosphor, such as used in the Model 1-S and the Prototype, is by its nature ‘darker’; it requires a higher beam intensity than the crisp green P1 or P31 phosphors used in many other models. The higher beam does make the P7 more vulnerable to burn-in.

    Different phosphors need different intensities to appear ‘bright’ – so some will burn faster

    Fortunately, the simple protection mechanisms in place in the Oscilloclock (we’ll get to these later) will avoid burn-in even on sensitive phosphors. The customer need not be concerned about this risk factor, and can select any of the available phosphors.

    The second factor is the thickness of the phosphor coating. The thicker the phosphor, the less burn-in for the same beam intensity. Some CRTs are infamous for having ridiculously thin phosphor coatings, making them extremely susceptible to burn-in. Sadly, some CRTs that are most readily available today fall into this category, and their data sheets even specify an incredibly short maximum longevity of 1000 hours. That’s less than 2 months of continuous use!

    Beware CRTs with short lifetime ratings – they may have ridiculously thin phosphors!

    Most CRT manufacturers did not publish lifetime ratings, nor did they publish specifications of phosphor thickness. In the Oscilloclock lab, I rely mainly on my and others’ experiences with the manufacturer, and pick and choose only the highest-quality CRTs. Expensive – but definitely worth it!

    The third factor is the use of any additional technology in the CRT that would allow for reduced beam intensities. The most common example is the aluminized screen, an additional coating on the rear of the phosphor. This coating reflects the light that would normally emanate from the phosphor towards the rear of the CRT, back into the phosphor (and the front of the screen). A much more efficient use of energy!

    However, this technology was a later development, so many CRTs with an aluminized screen tend to be rectangular and have an in-built graticule. These may not be as visually pleasing in a standard Oscilloclock as non-aluminized CRTs.

    2. Software (Firmware) protection mechanisms

    My favourite screensaver – Flying Toasters!
    (Image used under Fair Use terms)

    Remember the phrase “screen saver”? In the pre-LCD monitor days, most computers employed some form of software that would stop the same image being displayed for too long, to avoid screen burn-in.

    While there is nothing as fancy as flying toasters, the Oscilloclock has several mechanisms in place.

    1. Hourly XY Bump screen saver
      This feature simply shifts the image by a small amount in the X and Y directions every hour. The shift pattern repeats every 31 hours (a prime number), to ensure that every hour numeral will be placed in every screen position.
    2. Auto screen switch
      This feature simply cycles through the screens (clock faces) at regular intervals, configurable from 0 (off) to 90 seconds. This is by far the most commonly enabled feature, as it allows one to enjoy all the Oscilloclock screens without touching the control!
    3. Auto power off
      Strongly recommended by Oscilloclock labs, this feature simply turns the Oscilloclock off after a period of non-activity (not touching the control), configurable from 0 (off) to 90 minutes.

      This may sound counter-intuitive, but in practice, nearly all Oscilloclock owners are comfortable to turn their unit on just when they intend to enjoy it, and allow it to switch itself off. The exceptions are clocks that are permanent fixtures in offices and restaurants, in which case the owners manually turn their clocks on and off together with other appliances in the premises.

    These features are of course highlighted in the Operation Guide that accompanies every Oscilloclock.

    Summing it up

    So there we have it – there’s not so much to be concerned about after all. While CRTs do have a delicate phosphor coating, by selecting a decent CRT in the first place and looking after it in use, the risk of screen burn-in is drastically reduced. In fact, in 7 years of constructing Oscilloclocks, as of today not a single unit has come back for a CRT replacement!

  • Metropolis Time

    In an earlier rambling, I introduced the Metropolis Oscilloclock, themed after the classic 1927 science fiction movie. The clock seems to have garnered some attention, and thanks to the kind folks over at Hackaday, I now have two additional facts to relate:

    1. The “Maria” robot in Metropolis inspired the design for C-3PO in Star Wars!
    2. Some folks have considered the Workers’ clock to be Decimal !

    The first point stands without dispute, but let’s take a closer look at this “Decimal” aspect, as I’d never considered it before.

    Decimal Time vs. Metropolis Time

    Below is what got folks interested – the 10 hour clock face. The Masters used this to dupe the Workers into believing they were working short shifts, when in fact they were slaving away for a full 12 hours. Ingenious!

    But this is not Decimal Time, where time is divided into units that are purely decimally related. Yes, there are 10 hours on the face, but there are 20 hours per day, and 60 minutes to the hour. And, if you bother to count the dots around the edge, you can see there are 72 seconds per minute. None of these are decimally related.

    Speaking of decimal time, I fondly remember a Metric Clock article in the April 1987 edition of Electronics Australia. Being but a wee lad at the time, I was gullible enough to believe that true Decimal Time was going to be introduced in Australia imminently. I ‘convinced’ my father (he led me on) that it was really happening, and I was just about to purchase the kit to build my own Metric Clock… when in the following month’s edition, the magazine came clean that it was actually an April Fool’s joke!

    But enough fooling around – let’s now take a closer look at the Oscilloclock implementation of Metropolis Time…

    Metropolis Time vs. Regular Time

    The two clocks in Metropolis differ only in one way: the length of an ‘hour’. This is easy to grasp, since there are 20 hours per day in one, versus 24 hours per day in the other.

    But from here, Metropolis messes with your mind! Below are some revelations that [Andrew] and I battled over numerous e-mails to come to terms with:

    • The hour hands on the 10h face and the 12h face must always be exactly aligned (they must go around at the same speed).
    • Since an M-time hour is 20% longer, the minute hand must go around slower.
    • To make the M-time minute hand go around slower, the second hand must also go around slower.

    Even if this makes sense so far, the crunch comes when you think about how to implement it. If it were a physical clock, the tick speed could be slowed and the gears could be modified to make the seconds and minutes go slower but the hour hand itself move at the same speed. Easy!

    But it’s not a physical clock, and in the current Control Board design, the tick speed is NOT readily adjustable as it is derived from the MCU clock, which all the critical display routines are optimised around. So essentially, the length of a second cannot be changed.

    Without changing the length of a second, how can we make the minute hand go around 20% slower? Well, there are only two options:

    1. Have 72 seconds per minute, with 60 minutes per hour
    2. Have 60 seconds per minute, with 72 minutes per hour

    We decided on the first option, and you can see from the video below that the second hand indeed moves through 360 degrees in 72 steps (actually half that, since there is a half-tick).

    The Metropolis 10-hour clock face!

    An interesting tweak here is the shape of the hands. Note that they have triangular outlines, to more accurately mimic the hands in the film. But computing the angles and projecting these outlined hands using Circle Graphics was a true challenge – especially as the current Oscilloclock firmware is written 100% in PIC18F assembly code! Assembly is great for optimizing timing, but with no maths related processor instructions or functions to leverage, this feature was a huge effort…

    Why assembly code? Just because I can!

    Digital Metropolis Time

    Everything was now all fine and dandy for the analogue 10h clock face, but what about all those nice digital faces that are stock standard in every Oscilloclock? Could I make Metropolis Time make sense in a digital format as well?

    Of course! Except there was one hitch. Since we have 72 seconds per minute, the clock would show times like 09:16:65. This would look odd. Andrew wanted to keep the seconds in the range 0-59, like in a normal clock. Something would have to give… but what?

    The answer was to simply ‘ignore’ one second in every six; i.e. the 5th second shows for 2 seconds before incrementing. This is easiest illustrated with another video (note what happens at the 10:57:55 mark):

    But easiest of all is to see this in Excel. The duplicate second is highlighted:

    Switching between Metropolis and Regular Time

    Now, let’s face it: Metropolis time is really not very useful in day-to-day life; not for us Masters. Andrew wanted to be able to revert all faces at will to show Regular time instead of Metropolis time (except the 10h analogue clock face).

    This was duly implemented during production of the 2nd Metropolis Oscilloclock – which will be presented in an upcoming post.


    If, like me, you are hopeless at simple time zone conversions but you’ve actually managed to fully get your head around the above, Congratulations! Stay tuned for more posts in the Metropolis series.

  • Spring… a beautiful time of year! I particularly enjoy the warm rains, with the soothing effects of raindrops pit-pattering into puddles outside my window.

    But no longer do I need to look outside! Inspired by a recent post on Hackaday, a suggestion from [A-Nonamus] in the neonixie-l group, and by Spring itself, I can now enjoy Timedrops on my Oscilloclocks:

    See this in HD, and find more exciting videos on my YouTube channel
    Music credits: Space Bazooka by Kirkoid (c) 2013 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/Kirkoid/43005

    Assembly?!

    A sprite engine
    A sprite engine

    The current Oscilloclock firmware is written entirely in PIC 18F Assembly. The Timedrops feature leverages a Sprite Engine module, first developed for Halloween Seasonal Treats and later utilized in the Santa’s sleigh feature.

    To display Timedrops, the sprite engine is initialized with 10 sprites – 4 digits for hours and minutes, a colon, and 5 ellipses as ‘ripples’. The 5 characters are set at the top of the screen with a randomized negative velocity. When a character reaches the bottom boundary, the sprite engine’s default explode sequence is started, and the associated ripple sprite is made visible and set to expand. When the explosion sequence for a character sprite is complete, the sprite is reset at the top of the screen.

    Looking for the source code? Sorry – refactoring is still under way, and the latest revision with the Timedrops feature will be uploaded in the near future.

  • Santa in your Clock!

    The world-renowned Santa Claus. How does he get in your house to deliver presents? Does he go down the chimney (if you have one)? Does he shrink and squeeze under your door? Of course not! What silly ideas.

    Santa simply converts himself into pure energy and beams in!! I’ve seen this glorious event myself, and now you can too – with the latest Seasonal Treats enhancement from Oscilloclock.com.

    Beam me in, Santa!
    Beam me in, Santa!

    Not only can you watch Santa on his travels, but you can even control where he drops his presents! Can YOU help him deliver the gifts?

    (more…)
  • Do chips have bugs?

    There are probably many people who think that microcontrollers are bug-free. After all, they are glorified integrated circuits; a hard-wired jumble of infinitesimal transistor logic gates. There should be no unexpected behavior, as long as you operate the device within the rated voltage and temperature parameters….

    Wrong!

    What we tend to forget from our CPU architecture classes is that a CPU actually has a program inside. Known as microcode, its primary function is to interpret each instruction into the right electrical signals to drive the various parts of the CPU. For example, an addlw 0x7F instruction might involve directing the ALU’s input to the next word in program memory (0x7F), and then telling the ALU to add it to WREG, with output set back in WREG. The microcode for addwf MyVar would be different again; it needs to get a value in RAM, and set the result back there too.

    Well, where there is a program, there will definitely be bugs.

    My first experience with a microcontroller bug cost me several weekends of frustration, fretting, and frantic but fruitless rework. Here’s how it happened:

    Oscilloclock Gone Wild

    It was the early days of the Prototype, And things were looking great! My dream was coming to fruition! Except… every once in a while, the clock would go absolutely berserk. Seemingly at random, it would start displaying crazy, meaningless images, and controls would cease to function. Sometimes it would recover; other times, it would exhibit brain death – requiring a hard reset.

    April Fool's? No - it's a PIC bug!
    April Fool’s? No – it’s a PIC bug!

    No amount of testing or experimentation could tell me what the problem was. I rewrote huge blocks of code. I removed massive chunks to simplify the code. I drank more and more coffee. Sleepless nights and grumpy days ensued, wasting my precious youth!

    (more…)