Firmware is very close, getting good results. Few small issues but I hope to iron those out soon.
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
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.
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.
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
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.
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?
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
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.
Ahh, first I will tell you that flexible consisting is very important to me:
-
I run long trains up steep grades, have to MU
-
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
-
I do cut helpers on and off, so need to be able to reconfigure consists
-
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
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.
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
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.
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.
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