DS64's, jmri, routes, and all that

[Bangorboy]

Gary, how are the wires connected to your Tortoise?

If they are soldered to the Tortoise board, I have no idea what's going on, so I'll be no help.

If you have soldered the wires to sockets that fit on the Tortoise, be scrupulous about alignment.  I had to put shims in the ends of the slots on my sockets to keep them centered.  If the socket can move far enough sideways, its contact for pin one can short pin1 to pin 2, the next shorts pin 2 to pin3, etc on over to pin 8.  With them all shorted together, you have a bridge from pin one to pin 8, across the outputs of your DS64.  This may not be a direct short, it could be fairly high resistance because of imperfect connections (which were unintended in the first place) allowing some potential difference to remain and giving you a reduced voltage reading.

I can't remember the size of the shims I used.  They were cut lengths from Evergreen stock, something like .080 X .060.  We talked about it in another thread a couple years ago.  I'll try to look it up.  I cut the stock long enough to hold onto with tweezers when the end was bottomed in the slot, glued it in place and trimmed it flush after the glue set for a bit.  I'll look up the dimensions if I can find the post.  The stock was chosen to fit the width of the slot in my sockets, and half the width of the slop the card could slide in the slot.

Going to look for the earlier post now.

[Bangorboy]

Sorry, Gary

Tried every search term I could think of, found nothing.  I'll try to measure one of my sockets under the layout tomorrow.

Bill

[GaryHinshaw]

Bill, the wires are soldered directly to the Tortoise contacts.  Further, I tested each output of the DS64 with the same Tortoise, so that was a controlled variable.  I did get a very prompt response from Digitrax early today and we both agree that it is almost certainly a hardware failure in the DS64.  I'm shipping it back for warranty repair.  Thanks for all your suggestions and searches though!

In the meantime, I have been doing some homework on RR CirKits components and I'm going to order a Motorman to try out as an alternative to DS64's.  The main advantage is that one board can drive 8 Tortoises for roughly the price of a DS64, which drives 4.

[Bangorboy]

I was beginning to wonder if the DS64 was bad, but didn't want to give up on troubleshooting... 

[carlso]

Well gang, we were optimistic but  no bueno. The changes we made to OpSw6 & 8 did nothing. I powered up the layout this morning, after being off since Wednesday, and all but 3 turnouts, out of 47, went into the thrown position. Back to the drawing board, just too bad Digitrax can't help.

Carl

[Bangorboy]

Carlso,

I haven't been ignoring your posts, just haven't replied because I didn't have any helpful input.  I still don't, unfortunately.

I have some DS64s that move turnouts and some that don't when I power up.  I find it annoying as well as you do, because I hate having things I program according to instructions do unexpected things.  I tried reading all the literature and changing the settings to power up to the last state, ad nauseam.  I never got them to work the way I wanted, and still don't understand why.  All this by way of saying I don't think the problem is new.  Maybe nobody ever presented it to Digitrax before, but I can't make OpSw 6 do anything that I understand in either state.

All this happened about the time I started playing with JMRI, and I just programmed the aforementioned Set Staging Mainline route to solve the problem with one click, so I could spend my time on pursuits which got me further on my way to an operating layout.  I may someday go back to troubleshooting this, but I have no plans for the immediate future -- too many other more productive things to do with my train time.

Sorry this isn't more encouraging.

You could set up a diode matrix to tap the inputs to each of your DS64s with one button.  The DS64 has a "common" output and an input for each section to trigger the turnout to the desired state.  Put a diode  in each line so they can't feed back through the single button.  I don't know if a DS64 has enough power to set all of its own turnouts plus those of another DS64 at the same time, nor do I know if that's a bad idea because of possible differences in potential.  However, you could set up a relay in place of the pushbutton for each DS64.  Then control all of the relays from a single pushbutton somewhere on the fascia, etc.  This would at least make it less of a PITA to set all the turnouts to a known state after power up.  (Or get JMRI)

Regards

[carlso]

Bill,

just to say that yes this has been presented to Digitrax, several times. I and one of TRW''s member and a Digitrax dealer have both called and talked to people at Digitrax. They told both of us that they do not know why this is happening. They even told the other man that they themselves had been able to replicate the problem but still they do not know why it happens. Seems to me that if you can cause it to happen then you should know what causes it ? ? ?
I am not a real fan of Digitrax at this point, for sure. Yes, you are correct, their "manuals and the way they are written" are poor excuses as help to a customer.

Carl

[C855B]

... They told both of us that they do not know why this is happening. They even told the other man that they themselves had been able to replicate the problem but still they do not know why it happens. Seems to me that if you can cause it to happen then you should know what causes it ? ? ? ...

You've made this statement before, so it's time to jump in here. Software and especially firmware is anything but an exact science. Given the overall complexity of the combination of the bootstrap (low-level initialization code), BIOS ("basic input-output system"), operating system (foundation programming) and the application (does your task), it simply is not possible to create every single line of code yourself. Programming is highly layered. You certainly don't know - and sometimes can't know - what is going on at the lowest levels that might be influencing your product's behaviors. There are unexpected surprises at every turn.

Just because you can duplicate a bug doesn't mean the solution is obvious. It just means you can duplicate the bug. Granted, that is frequently half the battle, but if there's something squirrely going on in the foundation code (that you bought from somebody else) and you don't have access to that code, then you are unlikely to fix it unless you successfully engineer a workaround. Happens all the time. Plus there are the "How bad is this problem?" and "Is it a full failure, or an inconvenience?" questions versus "How much is it going to cost to fix it?"

I'm not offering an excuse, as they really should fix an identified erratic behavior. I'm just managing expectations slightly in communicating from long experience developing software that it's frequently not as simple as you appear to think it is.

[peteski]

f. Programming is highly layered. You certainly don't know - and sometimes can't know - what is going on at the lowest levels that might be influencing your product's behaviors. There are unexpected surprises at every turn.

That is exactly why today's software sucks. It is so over-bloated and too many programmers are involved (each with their snall piece of the puzzle.

I remember the days where I had 4" tick bound green-bar paper listings of a microcode I used for troubleshooting CPU boards. I could follow each instruction and break it down to specific hardware state (since I troubleshoot the hardware).

Nowadays there are so many bugs in commercially released software that it isn't even funny.  Plus the functionality and ease of use is pretty much taken out replaced by flashy crap that doesn't really do anything useful.

Rant off!

But seriously, none of hardware and software/firmware used for DCC is nowhere complicated enough not to be able to debug it to a specific routing or even a line of code.  Yes, the prepackaged routines wan make this more difficult, but no impossible.  After all, the microcontrollers they are using are relatively simple (even compared to an iPhone's hardware.

[C855B]

"Amen" to your rant.

The problem with µ-controller coding "in the olden days" - Digitrak's level of tech - is you frequently relied heavily on licensed packaged routine libraries that were locked down and you had nothing more than binaries linked in with your application code. What's worse - again, Digitrak's 1980's technology - was a likelihood that the vendor no longer existed and the source code vanished with them. If I hadn't been burned by this several times during the '90s and '00s I wouldn't bring it up. It was very frustrating and motivated me to get out of the business. Not saying that this is Digitrak's problem, just opening up the discussion to the possibility they may control less than we hope they do.

[thread drift]

A similar "deep code" experience I had with this stuff was a new employer. They had a PDP-11/10 (early!) with a highly-custom multi-head disk drive for dynamic memory swaps. The six months prior to my arrival they had been fighting tooth-and-nail with the disk vendor about a recurring crash problem. My boss couldn't prove it was the disk, but it wasn't the OS or our code, which ran fine on the other half of the mirrored system. I spent something like two weeks poring over binary dumps and source code for the driver, finally tracing it to an intermittent on one head of 64 separate heads.

And these days we're talking about government agencies embedding malware into disk drive microcode. Try and debug that! Yikes!

[/thread drift]

[peteski]

And these days we're talking about government agencies embedding malware into disk drive microcode. Try and debug that! Yikes!

Yes, we call that "progress".  Just like giving up our personal privacy for convenience.  Especially when we are unaware that we are sharing that info (like GPS location tag embedded in a JPG snapshot) which in itself is not very secret and can actually be useful, when it easily falls into wrong hands, it can cause us lots of trouble.

[GaryHinshaw]

Carl, forgive me if this was already covered, but does your club use jmri?  Bill's approach of having a boot-up route does ameliorate the issue somewhat.  BTW, I think you said you had cascading routes set up in your DS64's.  Are you willing to try resetting the boards with OpSw7 to see if the problem persists without complicated internal route programming?

Since 1 out of 2 of my DS64's had a hardware failure on delivery, I am even more sanguine about them. So I am ordering some Motorman boards from RR-CirKits to try in their place.

[drift]Modular code exists for a reason: so the collective can accomplish more than the individual.   Like any solution, it's not a panacea, but is there really an alternative that delivers comparable performance?[/drift]

[carlso]

Mike,

I appreciate your comments and thank you for them, but the comment regarding "my thinking that developing software is simple" is sort of saying that I can't express my opinion. I and probably 99% of model railroaders  are attempting to use DCC to its fullest and are certainly not software engineers, so in my opinion, if I am going to develop, design the equipment and manufacture it, then by darned it better work. I don't mean partially work but rather all phases of the gadget should work. In this case they do not work properly. They should have been pulled from the market until they do. I can just see and read all the comments if a locomotive manufacturer put out a piece of junk locomotive. They would be verbally crucified on all forums. What is the difference with DS-64's. You may not, but many of our model RR community must get the most use out of the money we spend. So again, it should work if on the market.

I love you man, but don't tell me that I should accept mediocrity, please.

Respectfully,
Carl

[GaryHinshaw]

A brief update, mostly to vent.  I hooked up my two DS64's to the yard ladder and tried out some more jmri programming options.  Here is where I am at:

1. I first cleared the route table and rebuilt the turnout table in jmri.  6 of the 8 turnouts were working fine, each responding to their proper address and so forth.  The other 2 were dead because the last two outputs of my 2nd DS64 are toast (mentioned above - I haven't sent it back for warranty yet).  Except for that issue, so far so good.

2. I entered a new route table - one route for each yard track.  Despite Bill's advice, I first set the routes to activate on a given sensor, and to have that sensor activated when the turnouts were properly lined.  This led to very bizarre behaviour, along the lines of the looping the Bill described earlier.  What I saw was that, after I triggered a route from the route table, if I then went back to the turnout table and triggered from there, I would get many turnouts triggering from one address.  Somehow the route table was corrupting things, probably because of the dual use of sensors (but the logic eludes me).

3. I then redid the routes table with two sensors: a trigger and a separate status sensor (like Bill recommends).   This seems to work ok now, but somewhere along the way, the 2 good ports in my second DS64 dropped from +/-10 V to +/- 4 V, so the Tortoises barely respond to them now...  Perhaps another hardware failure in that DS64.  (I'm also not sure what line voltage to expect in a healthy DS64.  My input power is 12 V, but the output line voltage is only 10 V, with 1 Tortoise hooked up to each output.)

Lessons learned: 1) route and sensor logic are not very clearly documented in jmri, 2) the DS64 seems like a very flaky piece of hardware.  I have ordered some Motorman boards from RR-CirKits to try in their place.

[GaryHinshaw]

On a brighter note, I did figure out how to serve the jmri layout web page to other wireless devices (a spare laptop in this case).   It wasn't obvious which IP address to use in the client browser, but once that was clear, it was very smooth.  (Hint: start the WiThrottle app in jmri and it tells you what address it is advertising to throttles on the network.)  I was then able to pull up (semi) functional panels and operate them over the web.  This paves the way for touch screen control panels.