BLI/QSI Locomotive randomly stops on clean track?? Set CV11=0

[learmoia]

In talking with Dave V on his Digitrax Sound programming questions, I started thinking back on my early days of DCC (and the introduction of BLI/QSI Sound locomotives)...

I recalled an issue I discovered and found the fix...
I regularly notice someone asking about the issue (Locomotive Randomly stops)

.. but I rarely see the correct solution.  (I see pages and pages about.. Clean the track.. Clean the wheels, Clean Pickups, polish contacts.. Disassemble locomotive.. check wires.. and on and on... ) 

Backstory:
Years ago I had a BLI SD40-2 and would run it in a consist with several other non sound locos.. On a large club layout with multiple DCC Districts (Command station and Booster).  I would notice that the BLI Locomotive sound would occasionally go from Run to Idle.. (But the train would continue running normal).. Puzzled, I would adjust the throttle, and it would come back to life for a few minutes.. then repeat... Nudge the throttle.. restart prime mover.....Keep running.. (The train always ran.. never slowed.. never stalled.. Not dirty track.. )

Sooo.. Huh.. I took off the non sound units and just ran the the sound unit..
Run Run Run Run... Stop (Engine Sound goes to idle).. Didn't short.. Didn't stall.. Not on a switch.. clean track........(Nudge throttle).. Restart / Resume speed... Run Run Run Run Run Run... Stop.. (Engine Sound goes to idle).. (Nudge throttle).. Restart / Resume speed... Run Run Run Run Run Run...
... Ooookay...

Reads instructions in booklet.. Nothing there..

Runs the locomotive again.. but adjusts the throttle up/down 1 speed step every so often:  Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run Run (10 minutes.. no Idle Stop)..... Hmmmmmmm...

Reads 200 page QSI manual / Full CV List..........
CV11 Packet Timeout "The Amount of Time (seconds) the locomotive will run without an update packet from the command station."  Values 0-255 -- Default 10, 0=disable

Hmmm... CV11=0

Starts locomotive.. puts throttle on table... walk away... 10 minutes later... (Still Running!!!..)

AHH HAHH...


So.. If you get a BLI/QSI Locomotive and it stops for no reason at random spots... Set CV11=0 FIRST.. (Before you try anything else.)... If it still stops.. then dig into Track/Wheels/Pickups..

Here is why: 
You start the locomotive.. Run at 40... Run 35, Run 40, Run 35... Each change sends a packet to the locomotive and resets the CV11 timer.  Same thing if your switching.. 0-10-0-R-10-0-F-10-0... (no issues.)

However.. if you are running loopdyloop... Start Locomotive.. 40................................................................  The command station may not send another packet to the locomotive (or on larger layouts.. the loco may not get one).. and the timeout kicks in and shuts down the locomotive until it gets another "40" (or anything else).

The CV adjustment turns off the timer, and the locomotive will do 40 until it is told to do something else.

... And this is an issue you'll notice right out of the box.. so if it's an issue on your layout.. work it into your normal programming setup for any QSI locomotives.

The only down side is the locomotive will run forever until it gets a command from the DCC system to stop.

Hope this helps.. ~Ian

[peteski]

Interesting.

I own a Pricom Designs Pocket Tester, which is basically a DCC packet analyzer which monitors (in real time), the packet being broadcast over the rails.  I have snooped on Easy DCC and NCE layouts ant the command station sends refresh packets to all the locos in-use on the track (the ones dialed up on the throttles)  whether there are any changes at the throttle or not.  So, that loco running at speed step 40 will get regular updates over the rails.

I also had the Pocket Tester monitoring a Digitrax layout, and I think it behaved just like the other systems (was broadcasting refresh packets, with with no changes in any of the loco's parameters), but that was a while ago, and I don't remember it clearly.  I would think that something like refresh packets timing cycle woudl be defined in the DCC specs and all the manufacturers would adhere to it.


I do agree that on large layouts with lots of active locos on the layout, the refresh loop cycle can be longer, so maybe in that instance BLI locos can reach their packet timeout value.  Why not just increase the timeout value, instead of disabling it?

[Lemosteam]

Interesting.

I own a Pricom Designs Pocket Tester, which is basically a DCC packet analyzer which monitors (in real time), the packet being broadcast over the rails.  I have snooped on Easy DCC and NCE layouts ant the command station sends refresh packets to all the locos in-use on the track (the ones dialed up on the throttles)  whether there are any changes at the throttle or not.  So, that loco running at speed step 40 will get regular updates over the rails.

I also had the Pocket Tester monitoring a Digitrax layout, and I think it behaved just like the other systems (was broadcasting refresh packets, with with no changes in any of the loco's parameters), but that was a while ago, and I don't remember it clearly.  I would think that something like refresh packets timing cycle woudl be defined in the DCC specs and all the manufacturers would adhere to it.


I do agree that on large layouts with lots of active locos on the layout, the refresh loop cycle can be longer, so maybe in that instance BLI locos can reach their packet timeout value.  Why not just increase the timeout value, instead of disabling it?

Curious how this would affect a BLI loco running on a DC layout?

[learmoia]

Curious how this would affect a BLI loco running on a DC layout?

I don't think it would change anything for DC since it it shouldn't be looking for DCC packets when running in DC mode.

Interesting.

I own a Pricom Designs Pocket Tester, which is basically a DCC packet analyzer which monitors (in real time), the packet being broadcast over the rails.  I have snooped on Easy DCC and NCE layouts ant the command station sends refresh packets to all the locos in-use on the track (the ones dialed up on the throttles)  whether there are any changes at the throttle or not.  So, that loco running at speed step 40 will get regular updates over the rails.

I also had the Pocket Tester monitoring a Digitrax layout, and I think it behaved just like the other systems (was broadcasting refresh packets, with with no changes in any of the loco's parameters), but that was a while ago, and I don't remember it clearly.  I would think that something like refresh packets timing cycle woudl be defined in the DCC specs and all the manufacturers would adhere to it.


I do agree that on large layouts with lots of active locos on the layout, the refresh loop cycle can be longer, so maybe in that instance BLI locos can reach their packet timeout value.  Why not just increase the timeout value, instead of disabling it?

Since going back to N scale... I haven't messed around with it since JMRI came up with packet monitors...  I've only noticed the issue on large Digitrax layouts with multiple boosters.. (So it could be related to how Digitrax handles update packets on boosters..)

Also.. in reading up on some things for my post... It seems CV11 is a DCC standard for Packet Timeout.. but not everyone is using that way today.. (Digitrax Sound uses it to mute the locomotive for X seconds after it has been 'dispatched' (un-selected from a throttle).

~Ian

[lyled1117]

I can confirm this advice works well, have done it for several customer's locos and brought them back to 'life'. A QSI loco that seemed to be extra finicky on pickup was the Milwaukee S-class (261 , etc), this CV made a major difference. And as said earlier, it does not affect their DC operation. The CV applies to DCC operation only.

Lyle D

[learmoia]

EDIT: Disregard...
I looked up the Pricom DCC Tester and this would be a good tool to track down the root cause of the packet loss causing the timeout issue.

I've always been curious if it's an issue unique to Digitrax and QSI.. or if it's a layout network architecture or wiring issue.

~Ian

[peteski]

EDIT: Disregard...
I looked up the Pricom DCC Tester and this would be a good tool to track down the root cause of the packet loss causing the timeout issue.

I've always been curious if it's an issue unique to Digitrax and QSI.. or if it's a layout network architecture or wiring issue.

~Ian

Yes, it is a wonderful troubleshooting tool (and also just to have some fun snooping the DCC signal).  It can be tapped off any location on the layout, so it could detect poor DCC signal quality. It helped me troubleshooting several oddball problems.  Too bad they discontinued the production (due to the LCD display being discontinued by the manufacturer).

I actually don't like that LCD display - it has poor contrast, and it isn't back-lit.  One of my future projects is to figure out how to use a nicer display with a backlight. But that wont' happen for quite some time.  I did communicate with PriCom about this, and they said that they won't re-spin the design using a currently available display, and IIRC the reason was that they don't want to spent development time on a product which didn't sell very well.  Too bad.

[learmoia]

I'd imagine the poor sales are due to many people thinking 'JMRI does that for free'.. not knowing that JMRI just sees packets at the network level.. not the track level..

(Or poor advertising..)

It would be nice if they made a version that interfaced with a computer.

~Ian

[peteski]

I'd imagine the poor sales are due to many people thinking 'JMRI does that for free'.. not knowing that JMRI just sees packets at the network level.. not the track level..

(Or poor advertising..)

It would be nice if they made a version that interfaced with a computer.

~Ian

Pocket tester was out before JMRI got popular.

It does interface with a computer, but  basically it does a live packet dump via serial port.  Old school.  We are going back to 2005 (IIRC).  I tried it, but  haven't used it again. I find just using the built-in display quite sufficient.

This thing does it all - measures voltages, packet timing, errors, etc., etc., right at the track.  Download the manual and check out all the features.

[Hawghead]

Pocket tester was out before JMRI got popular.

It does interface with a computer, but  basically it does a live packet dump via serial port.  Old school.  We are going back to 2005 (IIRC).  I tried it, but  haven't used it again. I find just using the built-in display quite sufficient.

This thing does it all - measures voltages, packet timing, errors, etc., etc., right at the track.  Download the manual and check out all the features.

My computer doesn't even have a serial port, that is very old school.

Scott

[peteski]

My computer doesn't even have a serial port, that is very old school.

Scott

Not really. I use serial port console on iSCSI storage arrays  during troubleshooting, on almost daily basis. Often that is the only way I can work on a broken array.
You don't have one?  You can get USB/serial adapters very inexpensively, and if you have a desktop computer, there are PCI I/O cards which have serial and parallel ports on them.

And the current ESU LokProgrammer interface still uses a serial connection to your computer (it comes with a USB/serial adapter).

[nickelplate759]

Um... a USB port is a kind of serial port.  That's what the S stands for.

[peteski]

Um... a USB port is a kind of serial port.  That's what the S stands for.

True, but colloquially "serial port" implies RS232 interface.     Actually, serial type of interfaces are in use everywhere (Ethernet is a type of serial interface), and most new computers use PCI Express, which is also a serial interface.

[Point353]

I actually don't like that LCD display - it has poor contrast, and it isn't back-lit.  One of my future projects is to figure out how to use a nicer display with a backlight. But that wont' happen for quite some time.  I did communicate with PriCom about this, and they said that they won't re-spin the design using a currently available display, and IIRC the reason was that they don't want to spent development time on a product which didn't sell very well.  Too bad.

Any idea if the LCD display was a standard product, or was it in some way customized for Pricom?
It appears to be a 128 x 64 graphic module.
Is there any manufacturer's name and/or part number visible on the display?

[peteski]

Yes, I actually have all the specs for the display (not with me right now).  I'll let you know tomorrow.  There are other displays with the same interface, but the connectors are different and PriCom does not want to re-spin the PC board to adapt them to the other displays.  "Too busy with other projects", they told me.