Well I just got one of these throttles in the mail today. Now I can make the switch to DCC finally once Martin releases his board. Super excited to play around with this throttle. Its about the closest one can get to running the real thing. And that’s coming for a guy who ran the real things for 8 years.
You know, I was really skeptical about this thing, its darn expensive. But it is way way cool and if you are looking for ‘tactile feel’, this is it. And it does Xbee. I can’t tell you how happy that makes me. 
It’s certainly not cheap, but its about the cost of one if our large scale locomotives equipped with sound. I figure with plans for a small switching layout, I don’t need more than 3 or 4 engines so I can justify the cost. Heck with this installed and working on only 1 engine, I figure that might be all I need!
I’m super glad I kept bugging you about this.
Got the basic directed message stuff working with the Xbees. Still needs some work and the cosmetics are pretty boring but all the underlying message passing is working. Here is a link if you are interested:
Working on another widget - Protothrottle to Airwire. I’ve combined the Xbee and the CC1101 modem into a nice little ‘translator’ for Airwire. This is essentially a ‘computer controlled’ T5000, with the computer in this case being the Protothrottle. Protothrottle sends commands via Xbee, this intercepts those and converts them into the Airwire DCC stream.
Ken Brunt said:
Kewl lookin throttle. What’s the range on that?
Very Cool !
Martin stated earlier theoretical range 100 meters, but YMMV
Greg
I’m patiently waiting for the new ESU version 5 decoder to come out so I can play with my Protothrottle. Good excuse to finish my locomotive project first.
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