Tehachapi, BC

[GaryHinshaw]

Well, problem #2 is licked.  I trashed the entire applications/jmri folder and did a completely fresh install.  Panels are being served again.  Thanks to Randall on the jmri users list for suggesting this.

Problem #1 is annoying but harmless.  Hopefully a solutions surfaces soon.  Problem #3 is a complete PITA.  Thank you Digitrax....

[davefoxx]

3. Digitrax released some new firmware for their DT402 throttles and the UR92 duplex transceiver.  I updated my throttles to v1.7 with no problem.  Emboldened by this, I tried to update the UR92; it looked like the operation completed successfully, but now it is hosed.  Off to Digitrax to sort this one out...  Thankfully the plug-in throttles still work, and the WiThrottle server is fine too, so there are workarounds.

I didn't realize that the software for the DT402 throttles could be updated, but, after reading your post and researching the issue, there's no way that I'm attempting that.  Not only is my throttle working fine, but that upgrade is waaaaaaay over my head.  If I screw that up, there's no way that I would figure out how to fix it.  Oh, hell no!

DFF

[GaryHinshaw]

Hi Dave.  The actual process of upgrading the throttle was pretty simple: strip the loconet down to bare bones, download the file, open the jmri utility to manage firmware, click a few buttons.  But I've done a few of these now and I have two DT402's so I knew if the first one went south, I had a back-up.  I had been having some issues with the throttles picking up and releasing slots during sessions, so I thought this stability patch was worth a try.  It's probably not worth it for a single-user pike.

Aside: I much prefer how WiThrottle manages slots & consists.  It would be really cool if something like these suction knobs for touch screens were adaptable to WiThrottle.  I would ditch my Digitrax throttles in a heartbeat.

[GaryHinshaw]

Problem #1 solved!  Thanks to Walt on the jmri list. 

(For my future-self reference: disable "snap to grid when moving" *before* positioning connection points if you see a problem like this.)

[GaryHinshaw]

Another geek update: I now have 7 contiguous mainline blocks set up with block detection and I am very pleased with how well it is performing.  With just the default settings in the Watchman boards, I've had no issues with missed or dropped detection yet.  Detecting locos seems to be bulletproof, and detecting resistor-equipped cars seems to be as well, though I only have one test train so equipped still.

Now turn to jmri: I was vaguely familiar with the concept of memory variables for tracking train movements, so I read up on them last night and set them up for the detected stretch of mainline.  (It took all of an hour to code them up.)  The concept is this: occupied blocks can take a Value which can be any string variable (such as a train symbol or lead unit number).  You initialize the value by typing it into the block table Value column when a block is occupied.  On TBC, I would expect the dispatcher to do this when a train is given permission to enter the mainline.  When an adjacent block becomes occupied, the value of that variable passes to the new block which effectively tracks your train across the layout (without the need for transponding decoders).   I first tried a test run with the Loconet Simulator, then took it out to the layout to try it out in hardware: it works!!

Here is a screen grab showing a meet at Walong, where BNSF 4809 is holding the main while UP 6702 is taking the siding from the right: (ignore the crude signals - still a work-in-progress)



This shot shows what is displayed in the panel schematic, as well as the information stored in the block table.  I'm showing lead unit numbers in a small font, but that can be refined.  The direction of the train is shown in the table based on the sequence of block handoffs.  Some comments:

* Tracking requires that trains travel through contiguously detected blocks.  If a train travels into dark territory, the memory variable is nulled, and it has to be initialized by hand when a train re-enters detected territory.  But this is perfect for through trains on TBC.

* Detection needs to be reliable.  If it is lost momentarily, the variable is also nulled.

* In the meet example above, you could have a potentially ambiguous situation where both trains are within the siding limits.  How does jmri know which train left the siding?  By turnout state!  (That works too, but note that jmri will get confused if two trains occupy one block - the variables are again nulled.)

* The direction of travel shown in the block table is based on panel coordinates (north is up).  I need to see if I can override that to indicate railroad direction.  I'm pretty sure that is possible.

* All of this info is available to the dispatcher (of course), but it can also be served to operators with web-enabled throttles.  This suggests the possibility that sub-panels showing signal aspects can be automatically served to an operator based on unit number (known to the throttle) and location.

* Watching the panel track a train around the layout for the first time was seriously cool to the geek in me!!!   

It's almost time to start up some ops sessions again.  I expect the first few will be chaotic! 

[C855B]

Thanks for debugging this for me, Gary. [...maniacal evil laugh reverberating in background...]

[GaryHinshaw]

It should work really well for the GC&W.

I can also imagine setting up under-layout ambient sound effects based on train location and direction of travel: flange squeal, slack action, etc.  Not a substitute for on-board sound, but a complement perhaps, with a subtle bass boost.

[svedblen]

I can also imagine setting up under-layout ambient sound effects based on train location and direction of travel: flange squeal, slack action, etc.  Not a substitute for on-board sound, but a complement perhaps, with a subtle bass boost.

That was a really neat idea! Not for my modest layout, mind you, but for Mike's museum size layout 

[eric220]

Thanks for debugging this for me, Gary. [...maniacal evil laugh reverberating in background...]

[...echoing maniacal laughter...]

I will also be watching this one. Cab signaling is definitely the fastest way that I'm going to get signaling up and running.

[Santa Fe Guy]

Very cool find. Looks interesting however I think I might push the boundary too far on the SFRSD if I was to do this. Seeing trains move without transponding how neat.
Good find indeed.
Rod.

[GaryHinshaw]

Rod, if you have block detection enabled, it's super simple to implement, but it's only worth it if it advances your ops concept. 

Since trying this last night, my mind has been racing with the possibilities it opens up: context-sensitive control panels, surround sound, dispatching tools.  I'm giddy.   

[bdennis]

Very cool find. Looks interesting however I think I might push the boundary too far on the SFRSD if I was to do this. Seeing trains move without transponding how neat.
Good find indeed.
Rod.

Oh young grasshopper..
This is already set up on the SFRSD panel.. You just have not used it..
(it probably just needs some tweaking)...

Next time we have a session I will show you..
LOL!!!

[GaryHinshaw]

^^

Another brief tech note: I now realize that my plan to treat crossovers as single blocks is a bad idea if I want to use train tracking.  If the crossover is closed, two trains can occupy it at once on the parallel routes.  This confuses the tracking logic if the crossover is one block, but fortunately the jmri Layout Editor lets you specify up to 4 blocks per crossover: one attached to each connection point.  For physical detection, I am going to go with 2 coils: one per "turnout".  The two jmri blocks that form the straight continuing legs of the crossover will be assigned to the mainline block they connect to (as they are physically).

Fortunately I've only detector-equipped one crossover so far, and I have one extra Watchman slot in the district it resides in, so it will be a fairly quick fix to unsolder the feeders one more time and insert an extra coil.  Glad I though of this now, because it does affect how I distribute the remaining boards around the layout.  It actually requires a fair amount of forethought to plan the board distribution sensibly so you don't have too many long sensor leads or too many unused sensor slots.

-gfh

[Smike]

Extremely helpful Gary.     My layout is just getting off the ground in but thinking ahead on how I want to do blocks etc..

Do you have any partial diagrams showing the block configuration with the revision in the crossover area's? 

Thanks, Mike

[GaryHinshaw]

Sure, hopefully this is what you are looking for.  Here is a snippet from my Layout Editor panel (which can also serve as the dispatcher's panel):



This is shown in Edit mode where the circles indicate centres of distinct track segments and the green squares indicate connection points (it is important that all connection points be green, or connected, for the logic of Layout Editor to work properly).  I've shown sample block assignments in red.  The Layout Editor can assign a separate block ID to each leg of the crossover: here I have made the crossing legs separate blocks while the straight continuing legs are assigned to the same block as their connecting track.  (Layout Editor note: the program treats the leg with the blue connector as the primary leg and the other three legs/blocks are defined clockwise from the blue one.  The logical boundary between the crossing blocks is the midpoint of the crossover.)

Now consider the tracking logic: if the crossover is closed and blocks are occupied in the order 1:3:5, it will recognize this as a southbound (clockwise) train leaving Bakersfield, and vice versa for a sequence 6:4:2 (whether or not 3 is occupied at the time).  If the crossover is thrown, a sequence 1:3:4:6 will be recognized as a southbound taking the crossover.

Physically, if you constructed the crossover from stock turnouts, simply detect each turnout separately and assign them to blocks 3 & 4 in this example.  You'll want to make sure that you have included enough track in the straight routes to clear the fouling point of the turnout.