Problems with the clock

My software upgrade to include the graphical output window went smoothly enough, but I’ve started getting trouble with the clock mechanism. The first thing I noticed was that the manual advance button wasn’t working.  Obviously, stopping and starting the clock during numerous tests meant that it was slightly behind time and needed to be advanced manually.  I knew the GPIO was working because the moon lit up and the hands were advancing.  The most likely problem was a bad connection somewhere.

I checked all the connections and although some of the screws could be slightly tightened, this didn’t really seem to be enough to cause a problem.  Anyway, this got the button working again, but now both the clock motors are losing some pulses.  I have to wonder if the connectors on the Pi’s GPIO are not making proper contact.  It’s possible that in disturbing them, they have moved slightly as they are only connected by spring force.  Maybe there is the tiniest bit of corrosion causing the problem.  Otherwise, perhaps there is a problem with a component somewhere, although that doesn’t seem so likely.  Maybe I should buy a ribbon connector that would grip tightly.

The graphical interface

I have noticed that the graphical interface causes the Pi to run hotter – I am not sure to what extent this is caused when I RDP into the desktop, but it is running at over 50 % utilisation when updating, although it does drop to 0 % when idle.  When updating, the CPU temperature rises to 66 degrees, cooling to 56 degrees during idle periods.  This cycling range of 10 degrees each minute does seem rather undesirable.  Heat cycling can cause problems with connections and components. I could increase the interrupt timing to once every two minutes, but this might result in even larger temperature excursions.

Update on the temperature issue – 24th November 2018
Task Manager showed an increasing utilisation percentage, causing the temperature rise, and in fact there seemed to be two instances of Python3 running.  I started to suspect some sort of recursion, because it was taking ever longer for each update to complete, with long waits during the redraw process.  I wondered if this was due to multiple drawing to the same window, so I decided that instead of blanking the window with a coloured rectangle, which I thought would be quick and not cause a problem if I moved it, instead I would close the window and reopen it.  In trying this out, I realised that I was creating the window in the main program, but redrawing it in a subroutine, but I had not declared the instance of the window to be global.  It seemed that Graphics.py created another instance in the subroutine and perhaps it was creating a new instance each time I wrote to the window, although using some settings, perhaps that it was keeping local to itself, but this was clearly causing it extra work.  I’ve now made all the window and text object declarations global. Then I discovered the ‘undraw’ function to remove the old text before entering the updated text. (If you don’t remove the old text, it remains on screen, causing the text to ‘smear’.) The redraw now takes a fraction of a second, the utilisation has dropped to a typical value of 0 %, rising to 4 % momentarily during redraw. The temperature has stabilised at 47 degrees: result!

I should mention that if you open extra windows on the screen, Graphics.py tries to find somewhere to put the window: it tries to put it in the last place you moved it to, even though it is closed and redrawn. (I’ve realised that this must be handled by LXDE.)  Given the much reduced load on the processor, I was hoping that the power supply voltage would be higher and the clock movement would be more reliable, but this doesn’t seem to be the case, so more investigation is still needed.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.