Date   

Re: Question for QSI re: new automatic logon procedure for decoders

peteski7
 

If that is the case, IMO it is a strange name of the feature.
That would mean a bi-directional communication between the decoder and command station.  That would be similar to RailComPlus, a protocol already used by some European manufacturers.  But American manufacturers seem way behind the curve on this technology.  I also doubt that QSI will ever participate. After all, when was the last time there was a new QSI decoder produced?  I also doubt that any of the older decoders can be upgraded to communicate with he command station.

Peteski


Re: I need some clarification, now more!.

 

Peteski: You may have miss read what I meant. LOL I do read manuals. It's just that the QSI is so much more complicated than "say" BLI. Those are the main decoders I have. A Bachmann with it's cheapy don't count. So I am willing to go further into the QSI manual. But it's going to have to be bits at a time. (pun may be intended) So for example, these first CV's, 62/64 are the first. And then I will work on others. But for an amateur like me to go "whole hog" into the CV's is a mistake. I'm sure that even the more advanced model railroaders may hesitate at ESU if they are used to Tsunami or Digitrax sound. As for my use of the word "quirky". Look at the number of modelers that are abandoning QSI. Way too many. I won't abandon mine because it has cost me over $500 for my loco and I am not willing to spend any more. New decoders that could replace the QSI cost close to or over $100. In other words. I am not going to do it. Period. I will struggle with QSI. And as for asking for help on here. Isn't that what we are all on here for? To help others. I certainly appreciate you and the others that have been on here.
Morgan F Bilbo, DCS50, UT4D, UR93, SPROGIIv4, JMRI 4.24, Pennsy modeler 1952


Re: Question for QSI re: new automatic logon procedure for decoders

kjlovesya
 

Hi Pete,

  Clarification is needed.  I think it means that the decoder is automatically identified, including make, model and version numbers.   I'm just guessing.  However, since there is some kind of standardization mentioned, does that mean the manufacturers are involved?


KJ


Re: I need some clarification, now more!.

peteski7
 

Well Morgan, the trade-off between simplicity and functionality in sound decoders is that the better sound decoders are complex in order to maximize the sound fidelity.  Think of the QSI, ESU, and ZIMO sound decoders being like some esoteric HiFi home sound systems which have zillions of knobs, dials and sliders for the audiophile owner to mess around with.  There aren't many of those audiophiles around. Most average humans are happy with a simple Stereo HiFi system in their house, with just volume, balance and tone controls.

I suppose you can struggle through using a QSI (or ESU or ZIMO) decoders by asking others to help you, but if you aren't willing (or not able) to at least somewhat immerse yourself in the manuals to better understand how those complex decoders operate, maybe a better choice for you would be to use some more basic sound decoders.  Digitrax, and MRC offer such simpler decoders.  Then there are middle-of-the-road decoders like Soundtraxx Tsunami and TCS, which offer better quality sound than basic decoders, but that again also means that they are more complicated to set up (more CVs to mess with).

I don't really think QSI decoders are any "quirkier" than ESU or ZIMO.  They simply are very feature-rich (read: complex) sound decoders, These three companies also provide dedicated software/hardware to make their decoder configuration more intuitive.  None of the simpler decoder manufacturers do that (because it is not really needed).

As far as SPROG goes, (or any DCC system that uses programming track) goes, the problem is that when the DCC specifications were developed, there were no sound decoders to even consider. Sound decoders draw a lot more current (due to them containing all the additional sound generating circuitry), and that affects the operation on the programming track.  It is unfortunate but we have to live with that (or just go with simpler decoders).

Peteski


Re: I need some clarification, now more!.

 

Exactly, Peteski: I had downloaded that and was going to start to read it. At least for CV 62/64, etc. But as I may have said. Too much of this is way over my head. And yes, I know ESU are worse. But I don't have any ESU. And I only have this one QSI. So, I am just going to keep working on it. It is a most interesting "journey" as you can imagine. I don't know about you, or the others who read QSI forum, but: Don't it make you wonder "What the heck is so wrong with QSI being quirky or "difficult" when one looks at ESU and needs to wade through 5,000 CV's. And like QSI, need to buy proprietary additions to work the CV's properly. In both cases, trying to use a DCS50 alone/for example is a major headache. One needs JMRI and a SPROG or some sort of booster for the other PC interfaces. Even my SPROG needed a tweak to get it to read my QSI decoder.
Morgan F Bilbo, DCS50, UT4D, UR93, SPRO


Re: I need some clarification, now more!.

peteski7
 

Morgan,
I just uploaded the manual I quoted to the Group's Files section, only to realize that it was already there under slightly different name.
You can download that manual following this link https://groups.io/g/QSIndustries/files/QuantumDCCRefManual_5_2_0.pdf

Generally, the newer versions of manuals still have info that applies to older decoders. In this case the CVs in question seem to have the same functionality.  But sound decoders in general are rather complex pieces of electronics, that require reading their manuals to get most of their potential. If you think QSI is a complex decoder, you shoudl see ESU V5 decoders. 

Speaking of the Files section, there is a lot of good reference materila there, but it is a total mess to look through. I wish someone (group's owner?) would organize it better


Re: Question for QSI re: new automatic logon procedure for decoders

peteski7
 

What does that mean?  I never "logged onto" any decoder.

Pe


Re: I need some clarification, now more!.

 

Peteski: That's one of the problems I have. I have so many manuals that I had downloaded.  And none of them have 448 pages. The one I do have that does have 434 pages is: dated 4/18/14 Ref man for Quantum 3,2&1 vs 5.1.1 for vs 7,8,9. All other manuals have far too few pages. I had spent many hours trying to find the correct manual for my decoder. I had lost the physical manual and that is what really hurts. The manual you mention is not one I have. Next step is to see if I can download the manual you suggest. What really makes this confusing is that I bought the loco in 12/2010 and most of these manuals are dated 2014 or so. The manual I do have that is closest to 12/2010 is dated 8/1/09. All others are newer. And the one you mention is newer. Should I assume that if I simply download the newest manual available and it does verify that it covers firmware version 7, it should still be OK for my old decoder? I have no idea if it's a Q 3,2or1?  I did check the above mentioned one and found where they describe CV62 and 64 and based upon Yank's response, I think I understand why he chose CV62=00 and CV64=01. So I will try that and see what happens. Thanks to all of you that respond.
--
Morgan F Bilbo, DCS50, UT4D, UR93, SPROGIIv4, JMRI 4.24, Pennsy modeler 1952


Question for QSI re: new automatic logon procedure for decoders

kjlovesya
 

Are the people at QSI aware of this?   Does QSI have to change their firmware to accommodate the procedure?

From the open DCC forum:

Hello all,
 
there is a combined attempt from both Railcommunity and NMRA to standardize an automatic logon precedure for decoders. Starting back in 2018, new ideas were discussed amoung the opendcc community and in april 2019 a prove of concept was shown at Intermodellbau in Dortmund and convinced many vendors there.
 
Due to covid 19 there was a break in 2020, but now we are heading for the final spec. Hope we can go for a first release of the spec end of this year.
 
I'm just adapting command station and railcom occupancy detectors to bring up a working test environment.
 
 
best regards / Mit freundlichen Grüßen

Wolfgang Kufer
http://www.opendcc.de, http://www.bidib.org


Re: I need some clarification, now more!.

Barry Yankolonis
 

Morgan to answer a few points.  If you only use PT than  verbal read back offers little help and you are correct in your assement. There are  a lot of situations where you might want to use POM, for instance when trying to speed match engines.  Yea the verbal acknowledgement is a little redundant, but it does confirm that the decoder accepted and implemented the change.  Even though you are confident that you have sent the correct programing instructions to the decoder, in some cases, the decoder doesn't receive the change or gets it wrong.  That being said, sometimes, as in the case with NCE command stations, which I use, the command station transmits the data in rapid sequences, depending on the commanded changes and if the decoder is verbally responding to the first instruction packet it gets, it misses the rest and your commanded changes are not fully implemented. There are a lot of other variables that come into play when communicating with the decoders either being programming or just simple operating commands.  On one of the other web sites, they show oscilloscope displays of the typical command station outputs to the decoder.  The signal wave forms are not really great.  That the decoders are able to make any sense of the signals is rather remarkable, with the typical distortion in the wave form signals. The information states, that on average, a decoder can only read about 40% of the commands transmitted to it, but is able to comply because of the redundancy/rapidity of the commands being sent. 
I always set CV62=0 and 64=1.  To get engine speed in ops mode with engine running, hit F10 and you will get a verbal speed readout.  It's sometimes a little hard to decipher because the volume of the read out is a little less than the level of the"operational"  sound the engine is emitting.    
Yank 


Re: I need some clarification, now more!.

peteski7
 

Morgan,
Your questions about the verbal readback and acknowledgment features are answered in the QSI decoder manual.  The one I have is QSI_CompleteReferenceManualForAllDecoders_V5_2_0.pdf  Those features are only available on OPS mode (on main track).

See page 404-406. There is also mention of why having the verbal acknowledgment enabled can cause problems. See page 448.

Peteski


Re: Proto 2000 Wiring Diagram

peteski7
 

You're welcome Frank -- I'm glad I was able to help out.

Peteski


Re: Proto 2000 Wiring Diagram

ffbrehm@...
 

Peteski,

This helps tremendously, Thank you. I got it from a friend. I’m hoping to put it into an Athearn SW1500. Like you I also wish I could find a few more for some other narrow bodied locomotives.

Frank


Re: I need some clarification, now more!.

 

The response I was hoping for was via email. So we could communicate offline. But, that's OK. I appreciate your response - Yank: My signature block shows what I'm using. A Digitrax original Zephyr. I always update any other that is needed. Hence, JMRI 4.24. When I do programming, I use the SPROG ONLY. No connection to Digitrax. So, what I am saying is: When on the pt/w/SPROG. It currently shows CV62=1 and CV64=0. So I figure I need to change CV62 to 0 to turn off all verbal responses. But what I really want to know is: Why? Or if I  leave verbal on, what good is it, if I don't use POM. Since I do all programming on the SPROG with regular pt mode, and if I remember correctly, in Direct always. The verbal being on POM only? Why do I need it? Or, I can ask in another way. If I use the Zephyr and want to change a CV on POM, would the verbal be of any real use? I ask this because I know that on POM, the Zephyr can not read back. So, what I assume (That's dangerous, I know.) is that using POM, the verbal will tell me what I changed. But since that's what I did, the verbal only verifies. So that is redundant. ?? Am I right? And this is only the first question I have about QSI and CV's. The next is about what I said above. If I do use verbal, is there a speedometer that QSI has that will tell me what speed I'm running? If so, how is it used? As you know, the manuals don't really give detail - only the how to connect, not how to use. And then, it's usually buried so deep in the manual, I take forever to find it and then try to understand it all. Is this clear?
--
Morgan F Bilbo, DCS50, UT4D, UR93, SPROGIIv4, JMRI 4.24, Pennsy modeler 1952


Re: Proto 2000 Wiring Diagram

peteski7
 

Frank,
this is an OEM version of QSI Revolution decoder made for Walthers. It was used in the N Scale 2-8-8-2 loco and also in some H0 locos.  Where did you find that decoder? I could use couple more myself.

Here is the pin-out.  The unmarked pins on the lights (functions output) connector are likely electrically active.  I suspect they contain connection to ground (common negative) and 2 more function outputs. I have not yet determined their functions.  The headlight function outputs (F0F and F0R) have 1.5k ohm resistors on board (so LEDs can be connected directly).



Peteski


Re: Proto 2000 Wiring Diagram

ffbrehm@...
 

Hi Peteski

Guess my previous replay didn't get out. Yes, that is exactly what it looks like.

Frank


Re: I need some clarification, now more!.

Barry Yankolonis
 

HI Morgan,
Since you haven't got much response, I'll try to help.  First off, what DCC Command System are you using?  That will help clarify some of the issues with the CV62 and CV64 settings.  If you are using an NCE control system, then you definitely need to have CV 62 set to 0 when you are trying to program an engine and set or reset CV's.   CV64 is verbal response in operating mode only.  Let me know what system you have and we can go from there. 
Yank


Re: Proto 2000 Wiring Diagram

peteski7
 

Frank,
Does your decoder look similar to this one?


Peteski


Re: Locos shutting down

Paul B/Indy
 

Excellent info.  I belong to a ‘remoter and regear’ list, and we just discussed this about P2K engines…

From the list… re: the bearings on the shafts/axles

"They are also the same material as the worm shaft bearings and motor bearings.  I think they either swell or corrode or both.  The result is binding at multiple points.  They resemble Athearn’s oilite bearings in terms of appearance but they don’t perform the same way.

Everybody has different issues but some have soldered jump wires directly to the axle bearing blocks to improve pickup.  Something is clearly amiss here.”
 
Note that this mentions both ‘binding’ and ‘jumper wires’.  Two diff issues, but your issue is included.  (the discussion was much longer than this one clip)

I suggest that you replace the bearings with Athearn oillite bearings or resign yourself to using a conductive lube periodically.  The power/electricity is not getting from the track to the decoder.  Not a QSI issue, rather, it is a P2K issue.

Good luck!

Paul B/Indy


On Jul 31, 2021, at 7:00 PM, Ray Di Ciacca <raydiciacca@...> wrote:

This does not happen at the same time Each loco is the only one on the layout and it happens on two separate layouts. the first time it happened I sent the complete loco after many comments from Kelley to QSI he said he found it was a conductivity problem, spray the axels with fixit D5 and sent it back. this was fine for a week the it started again. I find it odd that all these locos with factory installed decoders relatively new units all have the same problem.
Ray

On Jul 31, 2021, at 6:39 PM, Steve Haas <Goatfisher2@...> wrote:

Ray Di Ciacca comments: 
 
“I have now come across three diesel locos that shut down for no apparent reason. They are running fine then stop dead. they are all Proto 2000. I have cleaned the wheels, but this is only a temporary fix.The stop then start up again but as soon as they move they shut down. Any suggestions.
Ray”
 
Ray,
 
Greg and Phil have both provide good suggestions giving you things to check out.  Here are a couple other thoughts to help you resolve this:
 
  1. You mention this happens with three engines; 
    1. are these in consist and on the track at the same time, 
    2. in consist, but only one on the track at the same time,
    3. not in consist and on the track at the same time, or
    4. not in consist and only one on the track?
  2. You mention start then stop, then start again.
    1. By far the most common cause of this behavior is having the engine(s)/consist addressed by more than one of your DCC cabs.  The engines are getting a “run at speed step X” from one cab, followed shortly thereafter by a “run at zero speed” from another cab .  When the command station checks with the first cab, it will again tell the engine(s)/consist to run at “speed step X”, followed by another conversation with the second cab that tells the command station to tell the consist to “run at zero speed”.  The result of all this is the locomotive behavior you see.
    2. A second possibility is an intermittent short in the wiring of one or more (or all) of the engines in question.  In this scenario the movement of the various components of the engine can cause a wire to move creating a short, causing either the booster or the circuit breaker to trip, causing the units to stop, only to resume movement when the booster/circuit breaker resets.  
                                                               i.      Pop the shell off the engine and watch closely as it moves
                                                             ii.      Check all the wires to make sure there are no strands of wire separated from the rest of that wire and inadvertently contacting something else, and
                                                           iii.      Check for any wearing on the sides of wires where the wire is exposed and could possibly come in contact with other wires and/or other components of the locomotive thereby causing a short. 
    1. A third possibility is one or more of the engines drawing too much current, again causing the booster and/or circuit breaker to trip to protect itself.  You also mentioned the three engines in question were P2K;
                                                               i.      Some early P2K engines (the E7’s come to mind, there _might_ have been others) had motors that drew excessive amperage.
                                                             ii.      P2K and other China built locomotives are notorious for lubes and grease that turn into solid “Peanut Butter” over time.  The best solution for this is to completely disassemble the mechanism, clean all parts thoroughly in Dawn and water, using a tooth brush (and other tools as necessary, then re-assemble the mechanism piece by piece, lubricating with _sparing_ amounts of the appropriate hobby lubes, oils and grease. Test as you go for fit and smooth, friction free performance.
                                                           iii.      While you have the motor out of the unit, check and make sure _it_ is performing well.  Motors used in P2K and other models have been known to lock up when left unused for extended periods of time.  Careful, sparing application of bearing lubes to the motor bearings will help here. If the motor seems to be locked up, apply a bit of gentle five finger torque to break it free.  Your motor should run smoothly with as little power as a 1.5 volt battery.
 
Hopefully this will give you some additional clues that will help you resolve this problem.
 
Best regards,
 
Steve
 
Steve Haas
Snoqualmie, WA
 
 
 
 
 
 
 




Re: Locos shutting down

Ray Di Ciacca
 

This dose not happen at the same time Each loco is the only one on the layout and it happens on two separate layouts. the first time it happened I sent the complete loco after many comments from Kelley to QSI he said he found it was a conductivity problem, spray the axels with fixit D5 and sent it back. this was fine for a week the it started again. I find it odd that all these locos with factory installed decoders relatively new units all have the same problem.
Ray

On Jul 31, 2021, at 6:39 PM, Steve Haas <Goatfisher2@...> wrote:

Ray Di Ciacca comments: 
 
“I have now come across three diesel locos that shut down for no apparent reason. They are running fine then stop dead. they are all Proto 2000. I have cleaned the wheels, but this is only a temporary fix.The stop then start up again but as soon as they move they shut down. Any suggestions.
Ray”
 
Ray,
 
Greg and Phil have both provide good suggestions giving you things to check out.  Here are a couple other thoughts to help you resolve this:
 
  1. You mention this happens with three engines; 
    1. are these in consist and on the track at the same time, 
    2. in consist, but only one on the track at the same time,
    3. not in consist and on the track at the same time, or
    4. not in consist and only one on the track?
  2. You mention start then stop, then start again.
    1. By far the most common cause of this behavior is having the engine(s)/consist addressed by more than one of your DCC cabs.  The engines are getting a “run at speed step X” from one cab, followed shortly thereafter by a “run at zero speed” from another cab .  When the command station checks with the first cab, it will again tell the engine(s)/consist to run at “speed step X”, followed by another conversation with the second cab that tells the command station to tell the consist to “run at zero speed”.  The result of all this is the locomotive behavior you see.
    2. A second possibility is an intermittent short in the wiring of one or more (or all) of the engines in question.  In this scenario the movement of the various components of the engine can cause a wire to move creating a short, causing either the booster or the circuit breaker to trip, causing the units to stop, only to resume movement when the booster/circuit breaker resets.  
                                                               i.      Pop the shell off the engine and watch closely as it moves
                                                             ii.      Check all the wires to make sure there are no strands of wire separated from the rest of that wire and inadvertently contacting something else, and
                                                           iii.      Check for any wearing on the sides of wires where the wire is exposed and could possibly come in contact with other wires and/or other components of the locomotive thereby causing a short. 
    1. A third possibility is one or more of the engines drawing too much current, again causing the booster and/or circuit breaker to trip to protect itself.  You also mentioned the three engines in question were P2K;
                                                               i.      Some early P2K engines (the E7’s come to mind, there _might_ have been others) had motors that drew excessive amperage.
                                                             ii.      P2K and other China built locomotives are notorious for lubes and grease that turn into solid “Peanut Butter” over time.  The best solution for this is to completely disassemble the mechanism, clean all parts thoroughly in Dawn and water, using a tooth brush (and other tools as necessary, then re-assemble the mechanism piece by piece, lubricating with _sparing_ amounts of the appropriate hobby lubes, oils and grease. Test as you go for fit and smooth, friction free performance.
                                                           iii.      While you have the motor out of the unit, check and make sure _it_ is performing well.  Motors used in P2K and other models have been known to lock up when left unused for extended periods of time.  Careful, sparing application of bearing lubes to the motor bearings will help here. If the motor seems to be locked up, apply a bit of gentle five finger torque to break it free.  Your motor should run smoothly with as little power as a 1.5 volt battery.
 
Hopefully this will give you some additional clues that will help you resolve this problem.
 
Best regards,
 
Steve
 
Steve Haas
Snoqualmie, WA
 
 
 
 
 
 
 


221 - 240 of 19168