know that Kyle put in a lot of work for the first “true” run of Tusk Hill – instructions, tokens, switchlists, everything. And I know that some people drove a very long way (Jim from St. Augustine and Ben from Celebration, and, taken for granted, Greg from Satellite beach). So we handed out paperwork, got the briefing and began.
Jim was working both the coal job and the tally sheet and he seemed to be getting his head around how the Tusk works and how things are represented. Greg was standing by to take the shunter position. I ran up the line, picked up my cut from the Branch, then returned to sort in Tusk Hill. Paused briefly to let a second empty hopper move rumble past. Then, as I was shunting my train back into order, disaster struck. The microprocesser under Tusk tower started to misfire. It would throw false signals, kick turnouts over, all sorts of things. Like, really, WTF?
We messed with it for a while – Kyle and I were both applying programmer debugging techniques to try to get a better handle on what was going wrong. Got some ideas but still not smoking gun.
All I know is that, as I write this, I am desperately hoping we can find (and fix) this problem without having to tear the tower apart to get at something.
Found myself thinking that night (as I lay in bed, disturbed by what happened) how sometime technology can bite your ass. Back in the DC days, you could trace down everything in your wiring. There was something physical you could look for when there was a short. Then came DCC. Now it could be a failure in the locomotive chip, a booster, whatever, but you simply couldn’t fix it – you could only replace it. And now, with the amazing (but now loopy) Tuscarora Interlocking, there is a lot going on under the baseboard that I simply do not understand (since Steve designed and installed it). Monday night we’ll flip it over and see if we can solve this.
I’m just sitting here in dread that maybe we won’t be able to fix it. We’ll see.
(Sorry guys, but it wasn’t the funny OpsLog you had talked about)