After giving the matter much thought I've decided that I cannot in good conscience agree to build any hardware for the Polar Express project. My expertise lies in component selection, overall system design, hardware/software tradeoffs, and firmware and software programming. I thoroughly understand digital electronics at the register ransfer level, and I understand analog stuff at the level of ADCs (analog to digital converters) and the like, but when it comes to the flow of electrons across pin/substrate junctions, or the soldering of wires, we are well outside my area of expertise and I have no desire to test my ability to learn this stuff. If hardware is going to fail in service I don't want there to be a hint of a chance that it was because of a construction error I made while building modules or FRUs (field replaceable units).
Also, I have spent some of my own money to try to make atil least one of my two portable computers useable for the Parallax IDE (interactive development environment) in order to create the software for the FRUs and any test rigs. If my efforts continue to be unsuccessful it will be necessary for the museum to purchase a Surface 3 with physical keyboard for my exclusive use through the end of Polar Express. My wife and I are way over budget this month and next and simply cannot afford to carry the museum on something as expensive as a $600 (or whatever) computer.
Now ... Last night you, Jack and I spoke of three phases to this project, which I discuss below. We also spoke not only of modules to be built as FRUs but also of module test rigs to enable newly built modules, and modules that are believed to have failed on the hill, to be checked out on a test bench using a known good module test rig.
Today you want nothing to do with anything beyond the bare bones seven FRUs required to light the wolves, the hobo, the elves and the signs, with no overtones of Phase I spare FRUs, Phase I module test rigs, and no traces of Phases II and III. This is fine -- I will program anything you ask for. However, I feel the need to explain in this email the differences between the seven modules you have asked for and the Phases I, II and III that we had agreed to yesterday evening.
I"m qualified to speak to these differences because of a) the Omnitech Robotics CANbus-based remotely operated mine clearing bulldozer project I worked on in 2003 for which I did all the outboard firmware and software, and because b) in 1987 I was sworn as an expert special investigator by the City of Philadelphia regarding the Building Control System for the then-new Philadelphia Jail (CANbus did not exist at the time), and because c) a judge swore me as an expert witness during an investigation of the Building Control System for the Annandale Youth Correctional facility in New Jersey (CANbus did not exist at the time). I have never testified in court because it was never necessary -- contractors realized that it was in their best interests not to challenge my findings and instead to modify and then complete their projects per my professional opinions and directives.
It is my professional opinion that below is what is likely to happen if we simply build only the seven FRUs you want built by the time of my departure from the museum for Southern California on Sunday, August 30, 2015. We'll take the Wolves FRU as representative of all seven FRUs ...
If the Seven FRUs Only Wolf FRU fails in service it will affect the entire Wolf lighting system on both sides of the track. Because of the noisy RF environment, failures of this FRU will take several forms including a) uncommanded operation of the Wolf FRU, b) commanded operation of the Wolf FRU that never happens, and c) unintended operation of some FRU other than the Wolf FRU. These failures are likely to be transient in nature and not repeatable for trouble shooting purposes. Worse still, it will be impossible to determine whether the Wolf FRU failed because of RFI (radio frequency interference) or because of a transient defect in the FRU hardware itself. A laborious set of pin functionality tests will be required to assess board health. If the FRU is left in service, the only way to recover from a Wolf FRU failure witll be to cycle power on the Wolf FRU in order to bring it to a clean state. All this because module testing stations are not part of the definition of the Seven FRUs Alone project you imposed today
My definition of Phase I would have created three spare FRUs for a total of ten, and it would have created at least one and maybe two FRU checkout testbeds so that a rapid distinction could be made between FRU hardware failure and FRU transient response to RFI, allowing for field replacement of FRUs with known good FRUs along with depot checkout and repiar of suspected failed FRUs.
Phase II would have added a failsoft capability to the lighting design. Instead of the single Wolf FRU taking out the entire Wolf lighting display, the lights on each side would be driven partly by Wolf FRU A and partly by Wolf FRU B. As a result, a failure of either the A or the B module would take out half the Wolf lights on both sides of the train. Recovery could be affected either by rebooting the failed A or B module, or by swapping a known good FRU in place of the failed A or B module, but it would be highly improbable that at any time there would be no Wolf lights at all.
Finally, Phase III would have used so-called distance coding of Wolf Phase II light FRU addresses in conjunction with code that detected and retried erroneous transmissions to achivee a higher level of reliability of communication in the face of unavoidable RFI. It would not have been as good as CANbus, but it would have been better than nothing.
I'm telling you all this because if, for some reason, the show were to fail due to RFI or module defect problems, I would want it clearly understood that you were warned beforehand, in the form of this professional opinion, about the risks and the difficulties of trouble shooting in a Seven FRUs Only project environment.