Forums » Power and Sound

List of newest posts

    • February 21, 2020 4:57 PM EST
    • Martin, I completely agree drawing the line in the sand every so often, cannot hit a moving target. I've been hot and heavy on the consisting feature with Dr. Ziegler of Zimo, and it can be a complex subject, if you want it to really "work for everyone".

       

      Craig: completely understand. I like building up my consists in front of people, I use QSI decoders so they have a pretty sophisticated/detailed startup set of sounds, so it's fun driving the locos together, but I use DCC as intended, i.e. try to do everything with standard NMRA functions, so ANY loco can be consisted in the same manner.

       

      As an aside, I have speed matched all locos, and actually set the scale speed to the speed step, i.e. speed step 48 is actually 48 smph... (of course I flatten the speed curve at the prototype top speed), this obviously lets me consist anything with anything, cutting on a Mikado as a helper in front of a brace of F3's, but also know exactly my scale speed at any time. It's funny how human perceptions of speed vary.

       

      Greg

    • February 21, 2020 2:36 PM EST
    • Greg,

      To make things even more complicated over on the Protothrottle groups.io list someone has come up with a way to make what would be similar to an advanced consist, but just changing a few CV values on the ESU decoders and using the "drive hold" feature. Press one button on the PT, the two locks run together. Press same button again, one locomotive "parks" and sits in idle, while the other one goes around it does it's own thing.

       

      For someone that is running track power, I don't think Martin's widget is a solution. Just use the standard interface that ISE makes for the PT. For us battery power guys, Martin's widget makes a lot of sense even if it has limits.

    • February 21, 2020 2:21 PM EST
    • On the consist line, the 0 is where the lead loco address would be.  Then you would click on the OFF button and that changes to FWD or REV depending on which direction the locomotive is facing.

       

      I guess for this release I will have to just go with simple consisting.  You make some good points however.  With some more firmware effort I'm sure I can get something more advanced working.  But for now, for the functionality I have in there, I'm freezing this release as everything (knock on wood) works.

    • February 21, 2020 2:10 PM EST
    • So the next step might be to route the sound control functions to only the lead loco, which would also involve determining which was is front, i.e. the direction of the consist... this would necessitate "knowing" the last loco in the consist too.

      Then you could try attacking lighting.

      Like everything in DCC, you can go wild for making it realistic.

       

      From the screen above, I do not see where you specify which loco is the lead loco.

       

      Greg

    • February 21, 2020 12:25 PM EST
    • Actually, I have consists built into the firmware.  You can leave the actual address of the unit alone and just enter the lead locomotive number in the consist address. Here is a shot of the programmer screen for a Receiver:

       

       

      The consist button is off, forward or backward.  Just place the value of the lead in the consist field and set which direction it is facing.  When the packet comes in from the PT, I check the consist first, if it's enabled, I use that, if not, I use the locomotive address.

      Then all you have to do to 'unlink' them is set the consist button to off. You can leave who it was paired up with in the field if you like.

      Conversely, Craig, your idea will work the same too, however there is no control over direction in that case so all the locomotives would have to point in the same direction.

       

       

    • February 21, 2020 12:24 PM EST
    • Ahh, first I will tell you that flexible consisting is very important to me:

      1. I run long trains up steep grades, have to MU

      2. Sound and lights in every loco, and nothing worse than having bell and horn come from wrong (or all) loco(s), or wrong headlights go on

      3. I do cut helpers on and off, so need to be able to reconfigure consists

      4. I "hand off" the consist to different operators / throttles all the time

       

      So, it becomes a complex issue, and I want support beyond what NCE does with advanced consisting, which is pretty much the state of the art right now.

       

      On types of consisting, most DCC people (including the NMRA) define "basic", "universal", and "advanced" consisting.

       

      Renumbering locos to the same address is basic consisting, and there's many reasons this is no good, basically kills #2 above, but also you cannot run locos backwards in a consist. Really a dead end.

       

      Advanced Consisting makes use of that feature in the decoder, and can do some very nice stuff "automatically", i.e. the loco can behave differently in a consist as opposed to how it behaves by itself. Solves a number of issues about which loco responds to bell and whistle, lighting of units not at the "front" and having a loco running backwards in a consist. The issue is that it's still not quite smart enough now for really prototype operation.

       

      The best bet is the "system" recognizes the consist as an entity, and you tell the system that loco's role in the consist, some of the things are like is this loco at the front, rear or in the middle... that is enough to handle which headlights to light under which conditions... it also solves where the bell and whistle comes from. You can also solve the loco in reverse in the consist issue.

       

      I'm actually working with the head people in Zimo to bring this level of capability into their DCC system, and it's complex internally, but done right makes it easy for the user and realistic.

       

      .. now climbing out of the rabbit hole ha ha!

       

      Greg

    • February 21, 2020 12:06 PM EST
    • Greg,

      Going down the rabbit hole a little bit with multiple units...

       

      My thought was the following:

      Permanent consists by matching both locomotives to the same "road number". Each units unique id can be edited by Martin's interface in a matter of seconds. When done, reset the trailing unit to original id.

       

      Example

      NP288 & NP 289. Martin's widget would read these as two different locomotives. Change 289 to 288 and voila they are " consisted". When done change 289 back 289 and now you have two separate locos.

       

      Option 2 for battery/non powered loco

      Install HO scale decoder in "dummy unit". Wire up extra battery like normal. Add additional wires for decoder control. Run both sets to a 4 pin plug.

       

      On the leader loco, 4 pin plug is divided again. Battery to battery. The decoder side goes to the DCC amp. Since the DCC amp is sending 1 signal out, you just are paralleling the existing signal.

       

      But can it work? I don't know.

    • February 21, 2020 11:33 AM EST
    • Thanks guys, I appreciate the detailed explanation. I fully understand the architecture that Martin has used.

       

      One thing for the future that might be interesting is being able to enter service mode (the "programming track" to people not following the NMRA terminology) from the "widget". I realize how much more work that would be because you now have to read back from the decoder, as well as limit the voltage and current to the DCC decoder. But, there are many CV's that cannot be changed in POM (programming on the main for our listeners).

       

      Martin, I do think that raising the abstraction of the "decoder address" to the receiver level is an interesting idea that can have many benefits of simplification in the system. True you cannot use NMRA "advanced consisting" directly, but retaining the consist abstraction a level higher has many benefits, fully developed with features I would daresay a superior solution.

       

      Thanks again guys for the clarifications and explanations.

       

      Greg

    • February 21, 2020 10:33 AM EST
    • Greg,

      What I've done is install a DPDT switch off my ESU track power pickup. One side goes to Martin's widget, the other goes to a USAT motor controller jack (jst?).

       

      In normal mode I can use the PT and Martin's widget to run things. To change CV'S, I flip the DPDT switch, plug in the LokProgrammer (that interfaces with my PC). Open up the LokProgrammer software make the CV changes like you would with JMRI and upload to the decoder. Flip the DPDT switch and I'm back in "run" mode. If I want to test features the LokProgrammer software has the ability to test the decoder and put power to the motors. I can "bench test" any changes with the locomotive sitting on blocks.

       

      Does this help?

       

      http://www.esu.eu/en/products/lokprogrammer/

    • February 21, 2020 9:05 AM EST
    • Yes, that is correct. Essentially, the receiver is it's own little private DCC system with the motor controller wired to exactly follow the logic level DCC coming out of the receiver. I should point out that I don't use the addressing modes of the DCC system, the decoder remains set to '3', the default. So in my implementation, there is no 'programming' track or anything like that.  No other device except the Receiver talks to the decoder so there is no need.  All addressing and consisting is done at the receiver level which makes things a lot easier.  I can listen for an Xbee broadcast from the PT for say address '2100' and if it matches my receiver parameters I can process it. if not, I throw it out.  I can match on PT address, 'base' address, loco address and consist address, all of these are stored in the receivers EEPROM.

       

      As far as the Protothrottle, it has no mechanism to set CVs. For the smaller scales, you use the DCC system the Protothrottle links to.  For my Receiver, you need the programmer. It is a raspberry pi Zero W configured as it's own little private wifi access point and web server.  It talks on the Xbee network using an Xbee connected to the Pi via USB.  You can use it to set the internal parameters of the receiver such as the address and servo limits, etc.  You can also send CV messages to the receiver which it then sends to the connected decoder.  The web app is written in Python using the Flask Web framework- very very easy to use if you have any programming background.  I've open sourced the flask code, it's on Github if you care to take a look.  With some more coding, you could construct 'decoder specific' programming pages, or even send out the PT broadcast messages to automate things.  The Xbee API is well documented, I'm glad the PT guys chose it, it's very powerful.

    • February 20, 2020 10:56 PM EST
    • Thanks guys, so, Martin, your receiver turns the commands from the Protothrottle to DCC commands, and then you effectively use the motor controller as what DCC guys would call a booster.

       

      So a question is, it seems that this setup cannot do DCC service mode, unless you can switch out the motor controller, is that correct?

       

      So is Craig running something different? Maybe it's just the wording. What re-wiring needs to be done to the hardware, if that is a trade secret I understand, but it's the world's cheapest booster, nice idea.

       

      Also, is there anything in the Protothrottle to have the user interface to be able to program CV's? Clearly no keyboard, but there are some times you want POM while running, not removing the loco from the track and hooking up to a programmer. It would be a pain without a keyboard, but things like changing momentum, selecting a different bell/whistle.

       

      Thanks, Greg

       

       

    • February 20, 2020 7:36 PM EST
    • For the record, all you need is a Protothrottle, my receiver and a $10 Cytron motor controller for 10A of DCC.  More than enough for any single locomotive- I don't think there are any decoders out there that will handle more than 5-6 Amps?   I've also updated my programmer so that it will allow you to send CV programming to the decoder.

      My receiver will also drive very large ESC motor controllers, I'm getting interest from the ride-on scale guys to drive 50Amp size units- I just sold 4 of my receivers to a guy out in Oregon that does control systems for the big trains.

      I seem to have some unexpected time on my hands so I've been updating the web site, there is more info there if you are interested.

      http://blueridgeengineering.net/

      Again, many thanks to Craig for testing and getting me into this in the first place.

       

       

    • February 20, 2020 7:13 PM EST
    • Greg,

      I'm using a ESU decoder (XL, but next one will be L as has different DCC settings for momentum. XL is Euro based, L is USA/NA based so the rate of decay is different), Martin's widget and a commercial DCC amp that Martin suggested to run the Protothrottle.

       

      No actual DCC system needed as I can do programming changes via the LokProgrammer.

       

      Hope this helps.

       

    • February 20, 2020 6:53 PM EST
    • So Craig, since you commented on my thread about the ProtoThrottle vs NCE setup, what are you using?

       

      From your posts, are you using the protothrottle to Airwire converter, i.e.

       

      ProtoThrottle >> Protothrottle to airwire converter >> airwire convrtr in the loco >> ESU decoder in the loco

       

      You never posted back as to exactly what the final solution was, but you referred to Martin's setup... which I thought was a Zigbee / Xbee receiver on a single board computer interfaced to a DCC decoder.

       

      Greg

    • February 21, 2020 3:56 PM EST
    • Greg Elmassian said:

      Actually pretty straightforward, there's a lot of users and it's pretty well supported.

       

      The interfacing part is well documented, and there is a list of what hardware is supported, and it is menu driven as you set it up:

      https://www.jmri.org/help/en/html/hardware/index.shtml

      most of the interfaces are usb or serial ports, some need little converter boxes, for example, my larger NCE system has a real RS-232 serial port on it, so hook that directly to the computer, or a USB to serial dongle. The NCE PowerCab system, being low cost, only has the NCE "cab bus", so NCE makes a USB <> Cab Bus "dongle" which looks like a COM port to your computer.

       

      The installation is pretty much straightforward download and install. A small linux host can be very inexpensive, although since I wanted something portable, having a screen, keyboard, mouse in the same package made a small Intel Atom-based laptop a better choice, since I also have my decoder programmers supported there for Zimo, Massoth, QSI, Phoenix, etc. So I have a portable programming station for virtually all the top brand decoders.

       

      The features are much more than I use, but here's the top ones:

       

      Menu-driven programming for many decoders - this has multiple screens for tons of decoders, and they are grouped by function, so you don't need the decoder manual, don't need to convert binary to decimal, and by just filling in the screen, you can program tons of CV's

       

      Hand in hand with the above is the Data Base, where you can keep information on your locos AND keep a complete set of the CV's as programmed. So, you can pull up the existing/stored settings, rewrite them one, a group, or the entire decoder. Saves you documenting separately what you set things to, makes it easy to copy settings to a new decoder (like if you have several of the same loco)

       

      Another feature is running cabs on the computer, you can select a loco, "push" the function buttons, run the loco from a small window on the screen, and you can have multiple cabs. Again, hand in hand with this is if your computer is connected to Wi-Fi, then you can run the "wi-fi server" which allows more cabs/throttles on virtually any Android or iPhone device, and the apps for the phones are free.

       

      There is also an entire section on automating trains, and displaying your layout schematic. I have not played with this, but it's very powerful.

       

      It's an unbelievably good bargain at FREE!

       

      Hope this whets your appetite!

       

      Greg

       

      Thanks Greg that will give me something to look at.

       

    • February 21, 2020 11:46 AM EST
    • Actually pretty straightforward, there's a lot of users and it's pretty well supported.

       

      The interfacing part is well documented, and there is a list of what hardware is supported, and it is menu driven as you set it up:

      https://www.jmri.org/help/en/html/hardware/index.shtml

      most of the interfaces are usb or serial ports, some need little converter boxes, for example, my larger NCE system has a real RS-232 serial port on it, so hook that directly to the computer, or a USB to serial dongle. The NCE PowerCab system, being low cost, only has the NCE "cab bus", so NCE makes a USB <> Cab Bus "dongle" which looks like a COM port to your computer.

       

      The installation is pretty much straightforward download and install. A small linux host can be very inexpensive, although since I wanted something portable, having a screen, keyboard, mouse in the same package made a small Intel Atom-based laptop a better choice, since I also have my decoder programmers supported there for Zimo, Massoth, QSI, Phoenix, etc. So I have a portable programming station for virtually all the top brand decoders.

       

      The features are much more than I use, but here's the top ones:

       

      Menu-driven programming for many decoders - this has multiple screens for tons of decoders, and they are grouped by function, so you don't need the decoder manual, don't need to convert binary to decimal, and by just filling in the screen, you can program tons of CV's

       

      Hand in hand with the above is the Data Base, where you can keep information on your locos AND keep a complete set of the CV's as programmed. So, you can pull up the existing/stored settings, rewrite them one, a group, or the entire decoder. Saves you documenting separately what you set things to, makes it easy to copy settings to a new decoder (like if you have several of the same loco)

       

      Another feature is running cabs on the computer, you can select a loco, "push" the function buttons, run the loco from a small window on the screen, and you can have multiple cabs. Again, hand in hand with this is if your computer is connected to Wi-Fi, then you can run the "wi-fi server" which allows more cabs/throttles on virtually any Android or iPhone device, and the apps for the phones are free.

       

      There is also an entire section on automating trains, and displaying your layout schematic. I have not played with this, but it's very powerful.

       

      It's an unbelievably good bargain at FREE!

       

      Hope this whets your appetite!

       

      Greg

       

    • February 21, 2020 5:41 AM EST
    • Greg Elmassian said:

      the jmri component is pretty simple, in this case, there is a usb to nce cab bus interface

       

      is your question about the interfacing, or installation, or use/features of jmri?

       

      Greg

       

      All of the above to different degrees, mostly interfacing, the installation I think I can find on the net, uses/features again on the net if all else fails  asking someone who knows. 

       

      Big learning curve but willing to learn.

       

    • February 21, 2020 2:53 AM EST
    • the jmri component is pretty simple, in this case, there is a usb to nce cab bus interface

       

      is your question about the interfacing, or installation, or use/features of jmri?

       

      Greg

       

    • February 21, 2020 2:12 AM EST
    • Greg Elmassian said:

      Right, you have a command station and sophisticated throttle for $160, super deal.

      Yes, Raspberry Pi would be a good choice, of course since I got an entire laptop with wifi, screen, keyboard, touchpad for $70, going to be hard to beat.

      The output of the standard PowerCab is 2 amps but only 12 volts, kind of low for G scale, but like I said, $50 for a 5 amp booster, and a 5 amp laptop supply at 20 volts is cheap.

      As soon as I can get the new board, will indeed have a picture of it in a cigar box.

       

      Greg

      Greg,

      Not sure if I clearly explained that I am planning on using it on HO layout, so the booster would not be necessary as the 2A 12V is more than enough for my locos.

      It is the JMRI component of the original setup that I am interested in.

      Is there anything on your site about it?

    • February 20, 2020 6:26 PM EST
    • Right, you have a command station and sophisticated throttle for $160, super deal.

      Yes, Raspberry Pi would be a good choice, of course since I got an entire laptop with wifi, screen, keyboard, touchpad for $70, going to be hard to beat.

      The output of the standard PowerCab is 2 amps but only 12 volts, kind of low for G scale, but like I said, $50 for a 5 amp booster, and a 5 amp laptop supply at 20 volts is cheap.

      As soon as I can get the new board, will indeed have a picture of it in a cigar box.

       

      Greg