Hal,
On 02/26/2016 09:39 PM, Hal Murray wrote:
[email protected] said:
Strange that at least 3 independant firmware trees/development teams should
chose the same magic wk860.
I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...
That sounds like poor software engineering. Or poor engineering management.
It's easy to say, but as work progresses over the years, it is hard to
revisit all aspects of the code and re-evaluate it. One has to adapt
humbleness to the task, try to check as much as possible, but still
accept that you can't find all the bugs. Often the need to finish new
products on time comes before, flushing out all the new bugs.
The wk860 is supposed to represent the build time of the software so it will
work for 20 years from when it was built rather than 20 years from when the
10 bit week counter last rolled over or 20 years from when the constant was
last updated.
Indeed. Just not quite the full 20 years.
That magic constant has to be pulled out to a module where it is visible
rather than buried deep in some large module. Then the recipe for releasing
software has to update it, either by having a step in the checklist where the
human does the edit or by running a script that does it. (Yes, you have to
start by having a formal procedure for releasing software/firmware.)
That assumes one can foresee this to become a problem. Most doesn't
consider it to be a recent problem. However, just updating the constant
won't work for the type of products we have here, as the boxes we now
see have problems was never updated. A battery-backed RTC clock would
have helped, but the battery would probably fail around now. EEPROM
updates in the boxes would have helped, but 20 years back EEPROMS
wheren't too happy about many updates.
I think it is better to realize that the solution was good enough for
the expected lifetime of the product.
I've made some design choices like this. Some of them have survived the
complete re-writes and still not greatly failed the assumptions. Some
have faired less well. Some of the design decisions I make can easily
live for 20 years, and the one thing I've learned is that it is hard to
balance longterm with practical design for the expected lifetime.
I think they did fairly well. For most systems, the remaining problem is
showing the time as being exactly 1024 weeks off, but all other aspects
working correctly. We can apply prior knowledge to correct the 1024
weeks offset and keep these receivers running way beyond their designed
lifetime. That's actually quite respectable in my book.
Best Regards,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
