Hi, firstly may I say how great this system is. I have been following this for some months and have read all the posts. Thanks to Greg, Twin Dad, Scott, UK Steve and others for all this great work. I have a system up and running using JMRI and WiFi Throttles. Works perfectly. I have also built two of Dave Bodnar's throttles with some modifications to the code. I have chosen to control turnouts with switches as I like the tactile approach. I am using an Arduino with code that is loosely based on Geoff Bunza's work. Everybody at my train club uses NCE throttles. Would it be possible to amend the DCC++ Base Station code to accept NCE commands? I guess the supplementary question is: what is the NCE command structure.
I am similarly wondering if it would be possible to use MRC throttles in conjunction with the DCC++ base station?? I have a couple of MRC Prodigy Express throttles that I would like to use. Anyone have suggestions? Failing that, I will forego the DCC++ base station and build one of Dave Bodnar's boosters to liven up the miserable 1.6 Amps from the MRC base station. I too am employing Geoff Bunza's ideas to control turnouts using 16-relay boards and tortoises via Gregg Berman's DCCpp_Controller in "Processing 3" software. The work of these three gentlemen (Dave, Geoff and Gregg) have helped immensely in turning my idea of a train layout into (almost) reality.
I've been researching the same question. NCE Cabs (e.g., throttles) communicate with the NCE Command Station using NCE's CabBus protocol; the interface is RS485. NCE Cabs run in 'slave' mode, the NCE command station is the 'master'. So, it's a bit more complicated than just making the DCC++ Base Station accept NCE CabBus commands -- the DCC++ Base Station must emulate a NCE Command Station: Set master mode and poll all NCE Cabs & request commands; then, Set slave mode and accept commands. The NCE CabBus protocol is well documented and available on NCE's web site. Short answer: yes, it's doable. Long answer: First, you need to add an RS485 interface to the DCC++ Base Station hardware. You'll almost certainly want to use the UART interface for this rather than emulate serial I/O in software. Second, you'll need to add a substantial amount of code to the DCC++ base-station code base to emulate an NCE Base Station. I've gathered all this info because I too am interested in doing this very thing. I've been working on a number of pieces: 1. Have a proof-of-concept software library done. Can interface with my NCE PowerCab, can read/write some NCE CabBus commands, but don't have all commands implemented. Did a test integration with the DCC++ code base, it compiled and ran (i.e., didn't crash - I want to finish implementing all NCE commands before spending more time integrating with the DCC++ code base. 2. I breadboarded the RS485 interface using these little boards: http://www.ebay.com/itm/5V-MAX485-T...210034?hash=item1ec5e618b2:g:qJcAAOSwWiBY~c4Y (you can find much cheaper ones with a bit of searching). Plugged in my NCE PowerCab and sent commands without smoking anything!! 3. I'm looking to build a DCC++ Base Station with a Meduino: http://www.ebay.com/itm/New-Small-M...6U2-Arduino-Mega2560-Compatible-/162264493523 Meduino's are Arduino Mega2560 compatible with, most importantly, 4 UARTs, which will let me dedicate one UART to NCE Cab Bus. Everything is chugging along more slowly than I'd like ... wife, grandkids, house repairs, yada yada ... I know next to nothing about MRC, but seem to remember seeing somewhere (MRC website??) it used a scheme similar to NCE for throttle-to-command station communication, so MRC-DCC++ should be equally doable.
I do believe the JMRI Dev team mentioned that they have a dongle that is used with OpenLCB to use different DCC throttles in conjunction with OpenLCB I am wondering if it would work with DCC++?
Lyncher, This doesn't pertain to the original question, but it does relate indirectly. For some time on a back burner I've had a project I've wanted to do that would operate on the NCE throttle bus. I've discussed it a couple times with Jim Scorce of NCE but I have yet to undertake it. In their earlier days (maybe the future still?) there were some plans by NCE to do some kind of signalling on the throttle bus. I've been wanting to implement this idea for myself and a modular group I belong to. What I want is a device that sends and receives data on the throttle bus so we can use an existing data path. A track connected stationary decoder won't do what I need as its unidirectional. As things get firmed up with your library, I'm going to be very interested in the results. I had originally contemplated doing my project as a PIC based device, but recently have considered changing over to an Arduino based something. The Aduino method means I won't have to build the processor, just the interface and drivers. I'll be anxiously awaiting developments. Lyle Dowell
Lyle, you and I are thinking along very similar lines. My thought was to add NCE throttle bus capability to DCC++ so that I could use my NCE ProCab to run my trains. And, like you, I'd also like two-way communication to control various accessory decoders. I'm concerned, however, that an NCE throttle bus runs at just 9600 baud, so loading that bus with the additional burden of two-way communication to control all of a layout's accessory decoders might be too much. Hence, my idea to use a Meduino with 4 UARTs for the command station -- I can split the load across two (or three) "throttle" buses - one bus would handle just throttles, the second (and possibly third) would handle accessories. I would definitely want the capability to send 'accessory' commands from my ProCab -- the command station would be smart enough to receive commands on the throttle bus and send them out on the accessory bus. Haven't started on modifying the command station code yet, but plan on doing it so that it's a conditional compile for the Meduino (and multiple UARTs). If someone wants to run everything on a Uno, with throttles and accessories on one bus (which should be OK for small layouts), that'll be possible.
Interesting idea, sounds very workable. In my case I don't believe I'm going to task the original throttle bus with what I want to do. I want to have a device that collects occupancy and reports it like NCE's AIU and drive signals in response to data sent to it. These are 'horrendously' slow events and responses in microprocessor terms of course or even throttle vs human terms. The NCE bus can be tasked a bit too much even with a medium number of throttles, so I may find myself incorrect of course. I want to use the original bus so we don't have to retrofit all of our modules with an additional bus. Lyle
DCC++ is primarily a bus for the locos (has the ability to do some command control ). Locos only provide feedback during programming so the bus is one way. OpenLCB is just for things around the track that don't move ( yes i know turnouts move). It uses a ‘Producer/Consumer Model’ aka post and subscribe system. With OpenLCB it is possible for a turnout to listen for messages to say yard turn out 3 and when it gets one run its command say set position to 2 and then post back to the "bus" yard turn out 3 is at position 2 it would also be able to be queried as to its status if it is designed to.
