Date   
Re: NCE Advanced consisting and QSI model 106 (Atlas)

Greg Elmassian
 

I saw this issue on all early QSI large scale units. I do not think it was ever solved on the first hardware version. I have not tested it on the titans.

For all I know, the bug is still there. I recommend you do not use the reverse bit in cv 29

Greg

Re: NCE Advanced consisting and QSI model 106 (Atlas)

kelly dorf
 

Hi Steve,

I can certainly send you an upgrade chip, to see if this fixes your problem. Send me the shipping details to qsindustries224@....

Kelly

Re: NCE Advanced consisting and QSI model 106 (Atlas)

waltweber@...
 

Steve,

"Years ago" is almost certainly going to come into play at our club - the fleet is around 120 strong, built up during our 15+ years of DCC operations.

Mobile decoders from Digitrax, MTH, NCE, QSI, Soundtraxx, ESU/Loksound , TCS, and BLI are present in the fleet. Upgrading everything to a more
consistent standard (maybe 2 basic and 2 sound) is both expensive and time-consuming, so the club defers making a decision.

Fun times, but it keeps me busy.

Re: NCE Advanced consisting and QSI model 106 (Atlas)

Steve Haas
 


>>>> The NCE post was meant to see if anyone else has experienced the problem - I posted under NCE since our club exclusively uses NCE Advanced Consisting,
follows the methodology recommended by Mark Gurries (and others) in https://sites.google.com/site/markgurries/home/nce-info/nce-consisting , and I am not
certain how other DCC systems operate with regard to this functionality. <<<<

>>>> One other member posted that he has also seen the issue with QSI decoders. <<<<

>>>> I'm hoping to hear from QSI's rep here that (a) this is a known problem with the firmware version referenced, and (b) it is fixed in a newer release. <<<<

 

Walt,

 

My biggest recollection on this topic is that it was limited to one (or perhaps a limited few) decoder model(s) years ago.  Kelly at QSI would have to speak to the models/revisions

 

Having read about this on one of the lists, if I did run into it, I probably unilaterally would have rewired the engine as that resolved the problem for that particular piece of equipment for eternity.

 

Best,

 

Steve

 

Steve Haas

Snoqualmie, WA

Re: NCE Advanced consisting and QSI model 106 (Atlas)

waltweber@...
 

Steve,

The NCE post was meant to see if anyone else has experienced the problem - I posted under NCE since our club exclusively uses NCE Advanced Consisting,
follows the methodology recommended by Mark Gurries (and others) in https://sites.google.com/site/markgurries/home/nce-info/nce-consisting , and I am not
certain how other DCC systems operate with regard to this functionality.

One other member posted that he has also seen the issue with QSI decoders.

I'm hoping to hear from QSI's rep here that (a) this is a known problem with the firmware version referenced, and (b) it is fixed in a newer release.

Re: NCE Advanced consisting and QSI model 106 (Atlas)

Steve Haas
 

>>>> QSI / Kelly Dorf - is the problem described in https://groups.io/g/QSIndustries/message/18384 a reproducible / known issue? <<<<

 

Walt,

 

This accurately describes the symptoms I mentioned in response to your inquiry on the NCE-DCC list.

 

Best regards,

 

Steve

 

Steve Haas

Snoqualmie, WA

Re: NCE Advanced consisting and QSI model 106 (Atlas)

waltweber@...
 

QSI / Kelly Dorf - is the problem described in https://groups.io/g/QSIndustries/message/18384 a reproducible / known issue?

Thanks,

Walt

Re: NCE Advanced consisting and QSI model 106 (Atlas)

waltweber@...
 

Lou -

CV19 is being set only under the control of the command station (NCE) Setup Advanced Consisting feature while on the main.

It is then being removed from the main and examined on the programming track using JMRI - no changes made there.

...walt...

Re: NCE Advanced consisting and QSI model 106 (Atlas)

Lou
 

Are you changing CV 19 when you make the consists?

 

Lou

 

From: QSIndustries@groups.io <QSIndustries@groups.io> On Behalf Of waltweber@...
Sent: Saturday, January 18, 2020 11:41 PM
To: QSIndustries@groups.io
Subject: [QSIndustries] NCE Advanced consisting and QSI model 106 (Atlas)

 

What follows appears to be a firmware bug in ho106f00 , build date 14-July-2004.
Is this a bug, and is it addressed in a newer version of firmware?

Summary: use of CV29 "direction bit" interferes with advanced consisting when locomotive is running "reversed in consist".

Details:

Factory configuration for two locos is "long hood forward" , so the CV29 direction bit is 0 (off).
Place the two locos on the track with long hood facing forward for the lead loco, and reverse for the rear loco. Create the two-locomotive advanced consist,
and it functions as expected. (Note, for the rear locomotive, the CV 19 direction bit is correctly set to "1", since it is running reversed when in consist)

Now, delete the consist and re-configure the locomotives for running "short hood forward" by setting CV29 bit 0 (direction bit) to "1".
Place the two locos on the track with short hood facing forward for the lead loco, and facing reverse for the rear loco.
Creating the advanced consist as before, and depending on the direction of speed commands to the consist the locos will move in opposite directions,
either toward each other (until they collide) or away from each other. (Again, examining CV19 the direction bit is "off" for the lead and "on" for the rear loco.)

It appears that the logic calculation is done incorrectly when both CV29 "reversed" is "on" and CV19 "reversed" is also "on".

We've taken to addressing this issue by popping the shell off and rewiring the motor leads, and remapping the headlight leads, but would much rather
use the firmware setting.

Thoughts welcomed.

...walt...

NCE Advanced consisting and QSI model 106 (Atlas)

waltweber@...
 

What follows appears to be a firmware bug in ho106f00 , build date 14-July-2004.
Is this a bug, and is it addressed in a newer version of firmware?

Summary: use of CV29 "direction bit" interferes with advanced consisting when locomotive is running "reversed in consist".

Details:

Factory configuration for two locos is "long hood forward" , so the CV29 direction bit is 0 (off).
Place the two locos on the track with long hood facing forward for the lead loco, and reverse for the rear loco. Create the two-locomotive advanced consist,
and it functions as expected. (Note, for the rear locomotive, the CV 19 direction bit is correctly set to "1", since it is running reversed when in consist)

Now, delete the consist and re-configure the locomotives for running "short hood forward" by setting CV29 bit 0 (direction bit) to "1".
Place the two locos on the track with short hood facing forward for the lead loco, and facing reverse for the rear loco.
Creating the advanced consist as before, and depending on the direction of speed commands to the consist the locos will move in opposite directions,
either toward each other (until they collide) or away from each other. (Again, examining CV19 the direction bit is "off" for the lead and "on" for the rear loco.)

It appears that the logic calculation is done incorrectly when both CV29 "reversed" is "on" and CV19 "reversed" is also "on".

We've taken to addressing this issue by popping the shell off and rewiring the motor leads, and remapping the headlight leads, but would much rather
use the firmware setting.

Thoughts welcomed.

...walt...

Re: QSI decoder in Atlas GP40 not working

Tom in Texas
 

I didn’t see any mention of trying a reset.

I usually use the 3 CV method
Set CV49 to 128
Set CV50 to 255
Set CV56 to 113

If it has a reed switch, the ultimate is to hold a magnet above the switch and then use an old power pack to apply a slowly increasing DC voltage

Tom in Texas

Re: QSI decoder in Atlas GP40 not working

kjlovesya
 

Hi Rick,

   If you want to use QSI's excellent repair facility, contact Kelly (his email is in a previous post above).   QSI is located in Oregon.

   If you are in the west end of the Toronto area, I can arrange to meet at our club.      The Delaware and Rutland Model Railroad club  Let me know, as I'll have to bring some equipment (programmer, computer etc.) to the club.    I cannot promise anything, but I can at least have a look.


Best regards,
KJ

Re: QSI decoder in Atlas GP40 not working

rickpotter66
 

Lou & KJ & Kelly

I have checked the wiring from the track to the decoder and it is connected. I do not have access to QSI Programmer. If I decide to return to QSI for repair, what is their address and what would be possible cost? Do they need KA and speakers as well as decoder with lights? Is there anyone in my area that has QSI Programmer (Toronto to Kingston in Ontario) that could check this decoder?

Tks
Rick

Re: QSI decoder in Atlas GP40 not working

rickpotter66
 

Lou and others

I have a DCS51 with a PTB100 for decoder programming. 

I have unplugged the motor from the decoder and applied DC power to the motor. The motor spins with no problem.

I cannot access the decoder using either 3 or the loco number. I can program both POM and paged mode, but nothing works with this decoder. I will check all the wiring, but cannot see both front and back wires loosing connectivity at the same time.

Rick 





Re: QSI decoder in Atlas GP40 not working

kelly dorf
 

Hi Rick,

If you decide to send in the decoder to QSI for test/repair, please drop me a line at qsindustries224@....

Thanks.
Kelly
QSI

Re: QSI decoder in Atlas GP40 not working

kjlovesya
 

Hi Rick,

  I experienced something similar with a club member's Atlas MP15-DC.   The decoder locked up with absolutely no response even on the club's NCE PowerCab based programming track.   I couldn't do a reset.   I took the loco home and, using the QSI Programmer with Q1a upgrade "inquiry button", was able to 'resurrect' the decoder.    N.B. the QSI CV Manager was not able to bring the decoder back to life.   Without actually upgrading the decoder, only using the Q1a upgrade software worked.

 The sound, lights etc., came back and the decoder worked.   However, in this case, every time the loco was throttled up, the loco might move briefly until the current draw tripped the short circuit protection.   The likely cause is a motor winding broke and the entire motor needs replacing.    A motor with a broken winding will work sometimes if the armature is rotated to access the working winding.

  Do you have access to a QSI Programmer?


KJ

Re: QSI decoder in Atlas GP40 not working

Lou
 

Hi, Rick.

 

Check all the wiring from the track to the decoder to make sure they are connected properly, soldered is best. Tug every connection to make sure it is actually connected. Check the wiring from the decoder to the motor also. Sometimes the wire insulation will hold the wire on but the copper inside has broken loose.

 

What do you mean by “ unplugged motor and it works”? Did you unplug the motor from the decoder and the decoder worked, or did you unplug the motor and test it on DC and the motor worked?

 

Could the decoder be programmed in a consist? Try to write a zero to CV19, and do it a couple of times.  Retest.

 

Can you read the decoder on the programming track?

 

Have you tried running the decoder on loco number 3?

 

Please provide an update on your results.

 

Lou

 

From: QSIndustries@groups.io <QSIndustries@groups.io> On Behalf Of rickpotter66
Sent: Tuesday, January 7, 2020 10:48 AM
To: QSIndustries@groups.io
Subject: [QSIndustries] QSI decoder in Atlas GP40 not working

 

Please advise possible action for QSI decoder in Atlas GP40 that is not working. Numbers I can see on decoder are 171-OV7-35-10  GP40  (C)2008 QSI. Loco was working but has now stopped and no sound. 
Have tried F6 several times and unplugged motor and it works.
Tks
Rick

QSI decoder in Atlas GP40 not working

rickpotter66
 

Please advise possible action for QSI decoder in Atlas GP40 that is not working. Numbers I can see on decoder are 171-OV7-35-10  GP40  (C)2008 QSI. Loco was working but has now stopped and no sound. 
Have tried F6 several times and unplugged motor and it works.
Tks
Rick

Re: Appreciation for QSI and Kelly Dorf

Murray Vince
 

I’ll pile on too. Kelly has been great. I had a very positive customer experience with QSI, due to Kelly’s interest, advice and follow through.

 

From: QSIndustries@groups.io <QSIndustries@groups.io> On Behalf Of mike brady
Sent: Thursday, January 2, 2020 4:08 AM
To: QSIndustries@groups.io
Subject: Re: [QSIndustries] Appreciation for QSI and Kelly Dorf

 

I"ll 2nd, 3rd or 4th that ! Kelly has done lots for me and QSI IS THE GREATEST !

Become a dealer, you won't regret it  !

 

 

 

Sent from my MetroPCS 4G LTE Android Device

 

-------- Original message --------

From: Bruce <perico65@...>

Date: 1/1/20 10:59 PM (GMT-05:00)

Subject: Re: [QSIndustries] Appreciation for QSI and Kelly Dorf

 

I totally agree.  Kelly has given me among the best customer service I've ever experienced.  Well said, Joe.

Re: Total Frustration with making a locomotive connection with Titan-U

Lou
 

Happy New Year folks.

I have made some progress on the programmer, but not as complete as I wanted. I originally had the programmer working with the QSI programs and JMRI. I have the programmer working again with the SILabs drivers but have not been able to get JMRI working again consistently.

I tried several times to totally clear out old drivers. I searched  the hard drive using every name I could think of and did the same with the registry. I tried all of the drivers from current versions backward to the 3.2 version drivers. I did a clean up after each version failed until I got to ver 3.2.

When I tried ver 6.7 I received an error message that the programmer couldn't find ver 3.2 drivers and failed install. After another drive clean up I installed ver 3.2 using the instructions from QSIS. The drivers installed completely and the programmer worked. However, I was not able to make the connection with JMRI because it wants to use a serial port which 3.2 doesn't have. Later software sometimes installed the virtual com poet but the programmer would not work.

The SILabs driver that initially was used to install the USB and serial port was lost and I have not been able to find it.At least I can use the programmer again I did some reading on the SILabs site about the drivers and using it with older equipment. If I understood it correctly the hardware in the equipment needs to be flashed with a different PID. Gerry Pruss came up with the fix for JMRI so maybe he can shed some light on this.

Good luck,

Lou