G Scale Model Train Forum banner

41 - 60 of 222 Posts

·
Super Moderator
Joined
·
4,960 Posts
Kevin, you are unfortunately exposing yourself as not reading or understanding the products enough to make statements like 99% of the time.
In AirWire people often change the frequency channel, not the dcc loco number.
You REALLY need to be more familiar before you start quoting statistics like 99%.
No, it is NOT 99% of the time it will be changed... remember that many people who run AirWire and/or battery often pair just one transmitter to one receiver/loco.
So just on this point I am in great disagreement with what you wrote.


I have not programmed the Airwire with a QSI receiver, that is correct. I have programmed QSI receivers in a DCC environment, where you need to change the address of each receiver to its own unique ID--typically the locomotive number--in order to control each locomotive individually. If I've got 6 locomotives I want to run from one Airwire trasmitter, cam I set all the locomotives to the same DCC address (for instance, the default 3) and select 6 different frequencies between the Airwire and its receiver? That'll most certainly work, though I'm still selecting unique addresses, though--be it via the DCC programming or via the receiver. To control multiple trains from one transmitter, there has to be a way of differentiating the signals, so you've got to make that distinction somewhere in the installation process. RCS uses dip switches to assign each receiver its own code. Aristo uses individual cab numbers. I'm not sure how the Spektrum radios that Tony and Del use differentiate things, but it's a unique address of some kind.
I think you need to speak to more battery people. Call TOC, and ask him. Ask Paul Norton. They will BOTH tell you that most users pair one throttle with one loco. I guarantee it. Paul is a big TE supporter, and is a member of a big battery operated club. TOC does not use the TE, but is a very well respected installer and guru of battery operation, locomotives, etc.
I know very well how typical battery R/C people operate their trains. I've been doing battery R/C since 1984! Tony and my dad were both very early pioneers of the control method. Tony went commercial, dad didn't. I've been following the technology's development from its infancy. I think that affords me a fairly good grasp of how people use R/C. And yes, the usual model has traditionally been one transmitter per locomotive, because that's what the technology afforded. Today, it's different.
Have you really USED both systems? More than 5 minutes? I'm not trying to pick a fight, but your statements indicate to me that you are not familiar with DCC.
As for DCC, I've stated repeatedly that I'm something of a neophite when it comes to DCC. I would never presume to be a guru in that regard. It's a complete foreign language to me, hence my phone calls to you when I need assistance. To conclude otherwise from my posts is to completely miss my message.
You also need to realize that the TE is constantly touted as being easier to set up, and "beyond DCC" and as I put in my previous post, that is sometimes true and sometimes not, and I gave specific, factual, measurable information, not opinion. (and I gave the TE the edge deservedly in one department)
Reread, and you'll find that I'm in full agreement with that--even to the point of saying some of Aristo's claims are laden with spin. That's advertising. You don't advertise without a degree of spin. You'll also find I've agreed with you and given DCC the clear advantage in a number of scenarios. I've maintained that position from the first time I got the Aristo system in my hand.
Any person can take each system and count the keystrokes to "connect" a loco. There is a vast difference in the number of keystrokes. THREE keystrokes on the QSI system, dozens on the TE. Do you contest this? If I changed the address on the QSI loco, it would STILL be way less.
No, I don't contest that, and I stated that very clearly, something akin to "Factually accurate" or such language. My contention is that in all practicality, people programming either DCC or the Aristo system will have a baseline set of criteria they want to set up. Neither system will take longer than 10 minutes to do--especially if the NCE system has "plain english" setups that older DCC systems have lacked. How often does one have to program their decoder? In the grand scheme of things, is this really an important issue--a deciding factor for purchasing a product? Overall simplicity of programming, yes. Number of keystrokes? Well, suffice to say my time isn't that important.
You are also hanging on saying that DCC needs people to pick a start voltage and top end and direction? You are very wrong here, most DCC systems are out of the box "good", in fact the TE has the problem that you have no idea which direction is forward, it's just an arrow.
I'm saying that they are features that can be programmed--quite easily--on both the TE and DCC-based systems--to get the most out the locomotive performance. It's mandatory on neither system. The only "mandatory" programmable aspect is the cab number on the TE. As for direction, I'm not sure where your criticism is being aimed. Since this is a comparison between the QSI (which is a decoder/sound system only) and the Revolution (A transmitter/receiver pair) the visual indication of direction cannot be a criteria for comparison because the QSI board can be controlled by various controllers with differing displays. The Airwire controllers use an arrow as well, so I'm definitely confused here. Other controllers may use a "FWD, REV" to indicate direction, but that's not inherent in the QSI board.
Again, the comparison is very specific, the QSI/Gwire and the Aristo TE, not the old DCC decoders from 20 years ago, not an ole LGB MTS system, not anything else. The QSI has good default settings right out of the box.
Again, looks like DCC bashing on DCC in general, not sticking to the comparison at hand. How would it be if I bashed the Aristo Revo TE here for the crappy 75 MHz system? Same thing, has NOTHING to do with this thread and this comparison.
But this is what you ARE doing, bashing the QSI because you claim you need to set start and top speed, and that CV's must be involved to setup and run a new loco.
Please get off the "CV bashing bandwagon", where opponents constantly try to scare people away because they have to "learn" CV's.
Er, please remind me where I stated that you "need to" set a starting voltage or top end speed, or "need to" learn the CVs. You have learn them in order to access the higher-end functions, but--as I've agreed with you--the newer controllers like MRC's Prodigy2 and (from your description) the new NCE system make programming many of the fundamental controls somewhat transparent. You do not need to speak "CV" fluently to do a basic programming of DCC-based systems. You do to control the higher end functions. Hopefully one day that, too, will be equally transparent.
I'm keeping objective, but it's sounding like someone has an agenda to bash DCC here. Lewis Polk definitely has stated this in his advertisements.
If you're referring to me having and anti-DCC agenda, you're greatly misinterpreting my position. I've stated repeatedly that I like the functionality that DCC gives you. It does require a higer degree of technical prowess to access these higher end functions, but that's about as "critical" of DCC as I've gotten. And even you've said that programming CVs takes some getting used to. It's not something a neophite picks up right away.
Let's keep this on the subject and objective and factual.
By the way I do not agree with your updated analogy, comparing a point and shoot camera with a bag of parts... I think your analogy went from bad to absurd, really... why are you doing this?
Because I delight in these attacks on your blood pressure??? ;)

Seriously, there's obviously a high level of misinterpretation going on here. You seem to be of the opinion that I don't like DCC, and am bent on bashing it. Nothing's further from the truth. If Aristo hadn't come out with their controller, I'd be using Airwire or NCE and QSI decoders in my stuff. I love the QSI decoders. They've got some really cool features, and I've enjoyed programming them in the DCC installs I've done. I've not done many, but the few I've done have been positive experiences. I'm still not 100% on what variables I'm changing when messing with individual CVs, but that's part of the learning curve to which I alluded in an earlier post. I personally don't find myself needing the higher-end functionality that DCC affords the user, so I'm fine living with the compromises of the Aristo system simply because I prefer its user interface. That's my personal choice; it's not gospel.

Later,

K
 

·
Premium Member
Joined
·
2,525 Posts
What I would like to know is how you can split the quotes and insert the reply so that the quotes are all in separate "boxes".
 

·
Premium Member
Joined
·
2,525 Posts
Then I cut and paste the text from the post to which I'm responding between the two tags.

OK I see how to do it. Thank you.
 

·
Premium Member
Joined
·
1,976 Posts
I've got a question about QSI and the sound part of that decoder:

Can it be programmed by the user with different sounds and functionality? What I am getting at is one of the reasons I pay more for the phoenix sound cards is the ability to load different bells/whistles and sounds and program them. I am just curious since I don't care about the comparision between the two systems.

PS. the programming cable is about $80 extra so add that to the total.
 

·
Premium Member
Joined
·
2,910 Posts
Mark:

Yes, you can program and modify the sounds--but you need to get the "Quantum programmer" interface, which is about the same price as the Phoenix software/cable. Once you have it you can modify sound files and cut and paste different components of a sound file to make a new file. For example, you can change the chuff, the bell and whistle, the air pump, generator, etc. There are about twenty dfferent whistles, as I recall, maybe more. You can modify the sound volumes relative to each other, and you can adjust the chuff rate to match your loco. You can change a diesel file to a steam file, and vice versa.


I've never actually played with the Phoenix software--it may allow you to do more stuff? Bruce Chandler was kind enough to use his Phoenix software to modify a Phoenix card I had, and I got a look at the software, but didn't actually mess with it myself.
 

·
Registered
Joined
·
318 Posts
Posted By East Broad Top on 07 Oct 2009 12:01 PM

The flexibility and complexity go hand in hand. It's not a bad thing, just the inherent nature of the beast. Take your digital SLR camera for example. It's got what's commonly called "idiot mode" in which it does all the thinking for you. It's a very simple mode in which to operate, and I use it a lot when I'm out and about shooting photos of the kids, etc. However, it is capable of being customized to the Nth degree--allowing the photographer a great amount of creative flexibility. I use that mode when shooting photos in the garden for publication. To get the most out of that level of customization, you have to know (a) what the controls you're altering affect the resulting photograph, and (b) how to alter those controls. The first requires a fair understanding of photography and lenses--something the basic user may not have. The second requires an understanding of how to program those variables on the specific camera.


Kevin


Lets use your camera analogy a little further.


With your camera you can use it in simple mode but to get its real advantages you must learn how to use and configure the customized features which must be utilized each time you desire to use the camera at its full potential. Said another way, to get the full advantage of the camera you must understand how to use the advanced features.

Not necessarily so with a DCC decoder. DCC is neither simple nor complex. DCC is a protocol which can be as transparent to the end user as the manufacturer wishes to make it. Simplicity or complexity is a feature of an individual product and most often pairing between system and decoder. My experience over the past 18 years I have been working on the evolution of DCC has been that most comments of complexity and simplicity of DCC can be traced to the choice of system the user has experience with.


True there can be a lot of features that the user can customize. But unlike your camera the end user does not need to either customize the features now does customization need to be done more than once.

Take the special lighting effects. You normally need to set the headlight effect to the desired lighting effect if your locomotive has that effect (like a mars light) But once set you simply turn it on and off. This means for example that the installer can preset everything for you and once set it need never be configured again.

This is one of the advantages of pre installed decoders. If you purchase a locomotive with decoder the manufacturer can configure the locomotive and absolutely no CVs need ever be know or modified. When we designed DCC CVs and other such terms were defined to facilitate communication between the developers. End users only need to know how to control and in some cases configure features. Take TCP/IP which we are all using in this communication. From an end user perspective is it simple, complex or transparent. The number of features is not a measure of complexity.

For the sake of discussion lets look at two very different decoders. The Bachmann decoder and the QSI decoder. The Bachmann has 10 CVs which allow the end user to set 9 different features. The reason for the difference is that some CVs use a combination of CVs while other features use only a part of a CV. I will leave it up to Greg to provide the number of features and CVs that can be configured with the QSI decoder but it is a ton more.

The complete list of user settable features for the Bachmnan decoder are

1) The user can set the address (CV1, CV17, CV18, CV19, CV29) 2) The user can change the voltage the locomotive starts to move (CV2) 3) The user can change the acceleration momentum (CV3) 4) The user can change the breaking momentum (CV4) 5) The user can place the locomotive in a multi unit consist (CV19) 6) The user can change the brightness of the headlight when it is dimmed (CV52) 7) The user can change which function which controls the headlight dimming (CV51) 8) The user make the locomotive work in DCC only mode (CV29) 9) The user can configure the decoder to work on very old DCC systems which only support 14 speed steps. (CV29)


That’s about it. Pretty simple, and best I can tell, the vast majority of users of this product only change the address as the defaults are reasonable. Of course the flip side is that its missing a lot of features some more advanced users like to have. That is the power of DCC. One size does not fit all. Using your argument, if the manufacturer puts in a lot of extra optional features it suddenly makes the product complex even though most users will still only set the address.

I do believe Greg is also correct that you are trying to categorize DCC with very little experience. I have an offer for you. If you pay for shipping, I will loan you a couple of different DCC systems and decoders you can try out. That way you can make comments from first hand experience.

Stan Ames
 

·
Premium Member
Joined
·
4,393 Posts
Stan

From your example...
{snip...}[/i] "The complete list of user settable features for the Bachmnan decoder are
  1. The user can set the address (CV1, CV17, CV18, CV19, CV29)
  2. The user can change the voltage the locomotive starts to move (CV2)
  3. The user can change the acceleration momentum (CV3)
  4. The user can change the breaking momentum (CV4)
  5. The user can place the locomotive in a multi unit consist (CV19)
  6. The user can change the brightness of the headlight when it is dimmed (CV52)
  7. The user can change which function which controls the headlight dimming (CV51)
  8. The user make the locomotive work in DCC only mode (CV29)
  9. The user can configure the decoder to work on very old DCC systems which only support 14 speed steps. (CV29)
That’s about it. Pretty simple" {snip...}[/i]
(emphasis added)
For an individual new to DCC, how is it NOT confusing and or complex that CV19 & 29 control multiple parameters?

Unless the individual...
[*] From previous experience understands.
[*] Register bit addressing, and...
[*] Hexadecimal to Decimal conversion. or...
[*] Calculates the proper decimal value using a vendor provided table matrix. or...
[/list][*] The manufacturer has made these actions 'Transparent to the user' via a plain English user interface, where they merely enable/disable a feature in a menu driven selection. Provided in the hand-held control unit and/or a separate computer software interface.
[/list]
 

·
Registered
Joined
·
318 Posts
Posted By SteveC on 08 Oct 2009 08:35 AM
Stan

From your example...
For an individual new to DCC, how is it NOT confusing and or complex that CV19 & 29 control multiple parameters?

Steve

The answer is simple, the end user should not have to know anything about these configuration CVs.

User know about features. Lets look at address. Lets say the user wants to know the address of the locomotive which is unknown to the user. That a simple question with a simple answer. But internal to the DCC protocol the question involves more.

The user asks the address and the system says the address of this locomotive is 463. Pretty simple.

Behind the curtain the system has to ask the decoder several questions.

1) Is the locomotive currently in a consist (information contained in CV19)
2) Does the locomotive have a short or long address (information (CV29)
3) If short what is the value of CV1, if long what is the value of CV17-18)

The answer to the above can be displayed to the user in about 1 or 2 seconds.

Look at this as you do your TV remote. You tell the remote to go to channnel 42. You do not know or care to know the codes the remote sents the TV to accomplish this task? But if you really wanted to you could indeed generate the codes yourself to cause the TV to do what you desire.

Thats part of the problem. DCC is a very rich protocol. True enough you can understand it at the bit level and do everything manually. But you do not have to and the common complex tasks can and are made transparent to you by the system you choose.

True indeed there have been systems in the market that provide almost no transparency. But that is more a statement on that system and not on DCC.

DCC is only a protocal which defines a standard way of communicating. It is neither simple or complex. The degre of simplicity or complexits is a statement about how a particular product has decided to implement the protocol.

Stan Ames
 

·
Premium Member
Joined
·
2,910 Posts
Speaking again as a DCC novice, I can say most of the time I'm only changing a few CV--mostly cv 1, for address, and 3 and 4 for momentum/acceleration. QSI's sound implementation is a little trickier, but not much, and i've used that to set nornal volume and mute volume and the relative volume of individual sounds. Using either NCE's throttle or the QSI programmer software, I've changed the default direction, and the max and mid and start volts, and a few other things. Most of the CVs I need to use on an operating session are automated--for example, consisting. I don't have to enter the CVs for consisting, I press some buttons and make some menu choices. I agree--you read Stan's measage and it looks like you need 4 CVs just for address. It's really much easier than that.

If you want to get in deeper, you can, whihc is what's part of the fun
 

·
Premium Member
Joined
·
4,393 Posts
Stan

To an end user that is new to DCC, what the electrical/electronic specifications are, and what the communication protocol specified is, are totally irrelevant to them.

What they are concerned with is getting their DCC controlled devices (e.g. locomotive etc.) to do what they want them to do, and that means dealing with CV's in one way or another. So regardless of whether it is technically correct or not, to the end user, DCC is/are the CV's they have to deal with. If the manufacturer doesn't provide a 'User Friendly' manner in which to deal with the CV's then as far as the end user is concerned the system is confusing and/or complex.
 

·
Premium Member
Joined
·
687 Posts
I have been a user of DCC like systems in HO dating back to the introduction of the CTC article in MR about 1980. I built that system then later used the Onboard Command Control before switching to DCC in the mid 90s. I currently use Digitrax along with about half the other small scalers in the area while the other half use Lenz. Although none of the modellers I know including myself would ever go back to cab control, none of us would say that DCC is very easy. We have taken to using JMRI Decoder Pro from our computers to program the CVs in the decoders which has simplified the programming task at the expense of course of getting the computer interfaced to the railroad.

Also debugging problems associated with a shutdown power district are never much fun ...

In any case, DCC is the best there is for flexible and non proprietary products and I am glad to use it ... inside. Outside where I have to put up with 6 months of snow and ice on the tracks, a location over 300 feet from the nearest electrical supply and long wiring runs, I find the freedom of battery power to be quite refreshing.

I am a member of that same large club referred to by Greg that Paul Norton belongs to that is committed to battery power. Up to now, the available technology has led us to use a dedicated tranmitter for each loco. We have many different RCS and Aristo installations having tried most every system over the years. Most have worked well enough though none were perfect. No one here has bothered with Gwire and/or QSI - Paul did obtain a system but has since sold it. The Revolution came on the scene about 6 months ago and now about half the members have bought and installed it - I suspect that we have a critical mass within our club now and most members will acquire it ... though most of us including myself will not convert locos which are running well with another system.

In our situation, two specific things probably tip the balance in favour of the Revolution. Club members most often do not have any track but run solely at Fred Mills' IPP&W (or occasionally on my own Northland) in the saturday morning operation. Most members own a few locos and will bring one out for the ops session - depending on whether the session is using narrow gauge steam or transition era diesels. It is convenient and less expensive for a member to have one Tx and a decoder or Rx in each loco - the Revolution makes trailing car installations less necessary and already there is a move to self install locos. Storing the loco parameters in the Rx may be better in some ways but is a non issue for a member with 3 or 4 locos to link with his one Tx. Remember, this is not like a large HO club layout where trains are assigned locos from the pool ... in our setup members mostly run their own locos. The Revolution comes out ahead in the choice of the single Tx because ... it has excellent range, it can be handheld easily (or carried in a pocket) - an essential requirement for operating when a swtchlist and other stuff must also be carried - plus it is relatively inexpensive.

The second point is that we do not use smoke units at all and sound installations are not very common. Battery/power car operation does not favour sound as the same car is used with multiple locos. I love sound but I'm also the first one to shut mine off when I'm doing some switching. It just drives me crazy ... That is perhaps the reason that QSI has not been on any club member's buy list and also perhaps why no one has really gotten bent out of shape with additional wiring to get sound with the Revolution. Paul has wired sound in one of his diesels with the Revolution but neither myself nor other club members have done so as of yet. Sound is expensive and not a priority for those of us engaged in an operating session though I suspect in time we will eventually add sound to our favourite locos.

In short, track power (traditional cab control or DCC or any DCC like system) is not going to gain much of a foothold outside in a land with snow cover from mid November till early April. The Revolution is not perfect but is a significant step forward from any of its predecessors for the kinds of applications that we have.
Regards ... Doug
 

·
Premium Member
Joined
·
4,393 Posts
Greg

I owe you an apology for contributing to the tangent that your topic has taken, I should have kept my comments out of your topic and started another, sorry.
 

·
Super Moderator
Joined
·
4,960 Posts
DCC is a protocol which can be as transparent to the end user as the manufacturer wishes to make it. Simplicity or complexity is a feature of an individual product and most often pairing between system and decoder. My experience over the past 18 years I have been working on the evolution of DCC has been that most comments of complexity and simplicity of DCC can be traced to the choice of system the user has experience with.
To take this comparison as Greg originally intended it--a straight comparison of the QSI decoder/sound module with G-wire receiver, the exact DCC interface (i.e, the thing you hold in your hand to make the train go back and forth) is not specified. By your description--which I fully agree with--this interface can be straightforward or complex, depending on who makes it. Some are going to be more intuitive than others. By that argument, then, the ease of programming the QSI board relative to a single complete product package such as the TE cannot be determined, because the interface doing the programming is not specified. Someone using one of the more complex interfaces will undoubtedly have a tougher go of programming the decoder than someone using the more intuitive versions. Now, if you were to specify a specific interface (Airwire, NCE, etc.) then a direct comparison of programming simplicity can be drawn. The only comparison viable comparison that can be drawn is to say that the QSI decoder does not inherently need to be programmed at all in order to get trains to run because of the default values, whereas the TE has to be linked, requiring more steps. I'm not doubting that, but it's my opinion (and it's just that--an opinion) that such a comparison does not reflect real world tendencies. The user who is drawn to DCC for its functionality is not going to be satisfied with setting everything to the default any more than a photographer drawn to the DSLR camera will be always shooting on automatic. That's not saying there aren't people who buy DSLR cameras and never take them off of "auto," and maybe I'm mistaken as to the number of people who use DCC and never bother customizing any parameters.

Using your argument, if the manufacturer puts in a lot of extra optional features it suddenly makes the product complex even though most users will still only set the address.
It has the ability to make the product more complex, should the user decide to go there. The user is under no mandate to do so. The overall complexity--as you state--is based not on the decoder, but the interface.

I do believe Greg is also correct that you are trying to categorize DCC with very little experience.
I suspect part of the problem lies in familiarity. Both you and Greg have lived and breathed DCC for something on 20 years. It's second nature to you. When an admitted neophyte comes forth with his perception of the protocol, your immediate reaction is to say he doesn't know what he's doing. To a point, that's a valid response, but it disallows for the learning curve involved. Another parallel, if you will--video editing software. I've used Avid editing software for 15 years, starting with version 1. It's the industry standard, capable of editing anything from home movies to the latest box-office attraction. I am as fluent with that software as both you and Greg are with DCC. If I were to sit you down in front of that software, your head would explode. I know exactly how you feel relative to a newbie's comments about DCC. When I train photographers and interns on the software, I scratch my head and say "it's so basic!" But it's not. It's only "basic" because I've done it every day for 15 years. I can talk someone through a procedure from my car without even having the software in front of me, as I know both of you can talk someone through programming DCC without anything in front of you. The learning curve on DCC programming can be steep and utterly confusing to someone just walking into the technology. I know I'm not alone in that characterization. How a system is perceived by the new user is every bit as important to its success as how it's used by those with experience. There's a distinct reason manufacturers are working to make the programming interface more and more transparent to the end user. You do that, you lessen the learning curve and make the technology more accessible to the average hobbyist. I'm all for that! Until that happens, though, DCC will remain something of a foreign language that needs to be learned in order to be fully mastered. It is exactly the fact that I don't have decades worth of experience that makes my characterization valid for what it is--a view of the technology from the neophyte's perspective. That is a perspective that someone who's been using a technology for any length of time has no way of fully comprehending. For anyone with experience, you simply forget what it's like not to have experience.

Later,

K
 

·
Registered
Joined
·
318 Posts
Posted By East Broad Top on 08 Oct 2009 10:51 AM

To take this comparison as Greg originally intended it--a straight comparison of the QSI decoder/sound module with G-wire receiver, the exact DCC interface (i.e, the thing you hold in your hand to make the train go back and forth) is not specified. By your description-

K

Kevin

If you go back to Gregs origional post at the top of this thread you will see he has specified both the controller (NCE) and the decoder (QSI) for the comparision. The only thing that does not make this an apples to apples comparision is that a specified sound unit was assed to the Aristo Revolution, a product no produced by AristoCraft.

It is a fair comparision to judge the complexity, ease of use, and feature set of the two systems. In doing so the manner which the NCE handheld is used to configure the feature set in the decoder is relevant and where the configuration parameters are storred is also relevant. So to is the complexity level of how the configurations are organized and documented.

I will intentionally stay out of this comparision but have posted to point out that whatever the complexity of the NCE/QSI combination is or is not has little relevance as dto the complexity or lack thereof of DCC in general. It is a very comon mistake to try to generalize on a technology from one sample. Consider how a user of a DOS PC and a user of a MAC would compare the use of SNMP and TCP/IP to exchange email. Neither would know or care about the power of the underlying protocols but each could draw conclusions on how easy it was to use based on their use of the upper level hardware/operating system.


Stan Ames

BTW the offer to loan you some systems so you can get experience and be more accurate in your pronouncements still holds.
 

·
Super Moderator
Joined
·
4,960 Posts
If you go back to Gregs origional post at the top of this thread you will see he has specified both the controller (NCE) and the decoder (QSI) for the comparision.
Mea culpa. Somehow that got lost in the debate as the Airwire and other DCC controllers got thrown into the discussion along the way. Thanks for pointing that back out to me. With a single specified controller, it is a solid side-by-side comparison. I've not used the NCE controller, so I don't know how user friendly the interface may or may not be to the DCC-neophyte. I'll take QSI's "both systems are relatively easy to set up and program" as an indication that there's a comparable level of transparency to the process between the two systems. It doesn't change my argument that QSI's use of the phrase "significantly more time consuming and complex..." relating to the programming TE system is laden with spin. It may be a factual representation of programming at a single level, but in "real world" applications, my opinion is that it's going to be a wash. Note that what I consider "simple" is subjective, so arguments relating to counting keystrokes, etc. don't bare out. I've programmed QSI decoders, I've programmed Revolution receivers. The menus on the Revolution are a bit more intuitive than the MRC interface I used for the QSI, but neither system was difficult in the least for comparable functionality.

The better test for any DCC interface is how simple it is to program the higher functions--functions which the TE doesn't have--functions which give DCC a clear advantage over other control systems. How easy is it to configure BEMF feedback to the sound system? How easy is it to set up auxiliary functions to control marker lights, smoke, various sounds, etc.? You know better than me the minutia that can be controlled via DCC. That's where the complexity of understanding CV coding rears its head. You've got to set this value to this, in order to adjust that value to that--for the newbie, it can be an unintelligible mess! That's what I'm still wading through trying to grasp. I'm getting there, slowly, but--as is popular to say, it's a long, hard slog. Make that aspect "relatively easy to set up and program" and DCC will take great strides to overcome its stigma of being user-unfriendly.

Later,

K
 

·
Super Modulator
Joined
·
20,517 Posts
Discussion Starter #57
Posted By markoles on 08 Oct 2009 07:01 AM
I've got a question about QSI and the sound part of that decoder:

Can it be programmed by the user with different sounds and functionality? What I am getting at is one of the reasons I pay more for the phoenix sound cards is the ability to load different bells/whistles and sounds and program them. I am just curious since I don't care about the comparision between the two systems.

PS. the programming cable is about $80 extra so add that to the total.

Yes Mark, actually it is a great system here, ALL the bells and ALL the whistles are in the sound file, so you can pick any of them. There is a default horn and an alternate horn (or whistle) available... you use function 11 to swap between them. Also a short press of the horn/whistle will (on most recordings) give you a different sound than a long "pull".

You can reprogram the QSI from a diesel to a steam, to an electric.

In addition, there are a lot of files already customized, but all of them have the ability to change without using a different file. You can change all kinds of things, the pump sound, dynamic brakes, blower, bell, 1 or 2 motors in a diesel, and on and on... way beyond what you can do with a Phoenix... you can also control these sounds from DC... if you run a single engine, you need a $45 box. If you need more, unfortunately you need a more expensive box, but it can handle 30 amps of locos... you can control all the sounds from DC and raise and lower the volume, and on and on....

Hard to post everything it can do...

Regards, Greg
 

·
Super Modulator
Joined
·
20,517 Posts
Discussion Starter #58
THANK YOU FOR YOUR COMMENTS AND CLARIFICATION STAN!

I thought I did set the stage, but it's almost like you have to restate the goal of the thread/question every "page".

It was looking like it was just beat up on Greg day...

There is light at the end of the tunnel.

Regards, Greg
 

·
Premium Member
Joined
·
170 Posts
"With the TE if you use multiple transimitters, you have to program each one and re-link"

I have no experiance with DCC or any other type of non TE control system so my post is in no way indicating one is better than the other.
I would like to clarify the above comment in the table. Yes, you have to program each transmiter. There is no clone function.
However, after programing, you can set each transmitter to "Multiple Transmitters". You do not have to re-link with each receiver. Programing a second transmitter is a PITA but having to re-link would be a real FPITA!

I found the comparison very interesting. Thanks for posting it.

Greg, what is needed to reprogram the sounds on the QSI board. Is it like the 2K2, just need the software and cable?
 

·
Super Modulator
Joined
·
20,517 Posts
Discussion Starter #60
Thanks Ward, so the link ID stays the same for the second transmitter, and you just set up a cab to a link ID? I was not clear on how to get a link ID "into" the TE throttle without re-linking. If you can explain that will help me from making the same wrong statement again,.

Yes, the usb "programming cable" is $75-80 street price. Comes with a little power supply, and USB to your computer. You hook the output right to an isolated piece of track and program up there. When you program, you are installing the firmware to do all the DCC functions for motor and sound. There are new features all the time, like the new "rod clank" which is very cool sounding.

You can hear the rod clank well at 1:24 into the video.



Regards, Greg
 
41 - 60 of 222 Posts
Top