I am still a bit new to all this, I am still in the planning stage of building a layout and have been researching\learn for a month or two. Being a developer using Arduino instead of a commercial DCC system is very appealing. It seems common to run a "power bus" around the layouts. I was thinking if you accompanied that with an Ethernet type cable similar to loconet you would still have fairly tidy wiring. With an Arduino you have a bus already i2c, but it looks like its short range, which lead me to this:- http://mayhewlabs.com/products/i2c-power-extender You could have an Ethernet cable follow your powerbus then just cut and insert the Series Node from that site where you want to attach a i2c device. How much real overhead is there to decode a DCC signal and just use the rails as the bus? adafruit has many tiny Arduino compatible boards that are very small and cheap. here is one example https://www.adafruit.com/products/1501 only 7 bucks!
I think it is very typical to use the rails as the info bus for DCC signals to all components, and does not create an overhead issue. However, it's also typical not to use the rails as a power bus for external components. This is because you want all available current for the locomotives, and the only choice for a train is through the rails (unless large enough for on-board batteries). So it's common to power everything else via separate power bus wires (sometimes multiple busses for different voltages if needed). Also note that depending on the scale of the tracks, additional DCC feed wires are often required. In N-Scale, the rails have non-trivial resistance and the signal does degrade over longer distances. So adding in feeder wires at various points throughout the layout is quite common. Additional DCC feed wires also may be needed depending on whether you have reversing loops, block controls, etc.
Yes, with my new layout - currently in planning stages - I'd like to see minimal cabling in the form of: - DCC rail power (for loco's) and DCC signalling of loco's, turnouts, signals, etc - accessory power "bus" to actually power external components, turnouts, etc. as described by Gregg above - strategically placed Arduino based accessory decoders that draw on the signalling of the DCC rail bus but control power supplied by the accessory power bus through relays or the like.... per Gregg: "Would be great if we could come up with a robust design and mass-produce small ready-to-go units." I agree this would be great; something with selectable outputs: - momentary output for solenoid based turnouts (like my Maerklin units) - latching outputs for lights, motorized accessories, and the like - servers for animation, etc. ....I know, my wish list is growing.... Michael
I've started watching your video series Gregg, thank you for one sharing it with us and give me a moment to catch up and I'll have lots of questions being new to DCC let alone a system like yours. But it's sure worth the effort to learn. Thanks again
Hi Gregg, I was looking at the Arduino V2 code, and in the header section it describes the wiring for the Mega like this: I was under the impression that for a Mega only a single jumper is needed from pin 2 to pin 13 as shown in your video. A typo? Update: I just noticed that you had fixed this in the latest version. Thanks Gregg!
Hi Gregg, Today I finally had the time and the necessary hardware to hook up a test track, powered with a Mega. Fired up your processing sketch and - BAM! It worked right out of the box! I shouldn't have been surprised by this, but I gotta tell you - I still got a huge kick out of seeing the engine respond to the commands. I can only imagine what it was like when you first set this up yourself.. Thanks again for your great work on this terrific project! Regards, Kay
That's terrific! Note that I uploaded a small patch to the DCC++ Base Station last night that corrects a bug in the Mega logic for the programming track (the main operating track is unaffected). So please make sure download the latest version before testing out writing/reading on the programming track. Good luck!
My layout wiring looks like the inside of a pinball machine; copious wires running in many directions. My layout is 4.5'x8.5' with a twice around double track main with various yards and branches. There are 64 electrically operated turnouts. The track is divided into 70+ blocks in order to facilitate signaling and short circuit protection. I didn't use a power bus because each block is fed from a current limiting circuit (series light bulb). The topology is more star-like; the current limiting circuit boards are located in the middle of the layout with track power feeders radiating out to each block. I use Team Digital SMD turnout controllers. Each controller can handle 8 turnouts using either twin coil or stall motors. The SMD's are generally located close to their controlling switches and each switch has 2 or 3 wires. That's two wires per block and two or three wires per switch. On my prior layout I mounted the current limiting circuit boards and SMD's along the front fascia on a hinged mount. That location generated very large bundles of wire. Moving the boards to the layout center was my attempt to minimize wiring. The only simplification of wiring I can conceive would be for the current sensing and switch control to be implemented on a per-switch, per-block basis. These boards could be mounted at their required location thus minimizing the wiring.
Hello all! I've been eagerly following the progress here, and am getting ready to order the parts to make one of these. TwinDad, I'm curious as to what WiFi shield you are using for the WiThrottle code, because I'd to order one for mine so I can use the WiThrottle app when you finish the code for it. Also, are there any plans to make an on-board GUI and/or throttles for the DCC++ system? Thanks! Andrew
I have been following this project which looks excellent, a lot of work has gone into it, and the setting up and operation is very well described in both words and videos. I have loaded to BaseStation-Master to a Uno (genuine), and together with your Controller-Master and all seems fine. Track power can be turned on and off as designed, short circuit protection is working, and it seems that decoders can be programmed since the Write and Read functions appear to work ok. I'm sure it is me, but I cannot get any trains to move despite the throttle slider moving as expected. In other words all seems to be as expected but no movement. If you can suggest any obvious things to check then I would be extremely pleased.
I'm using the Adafruit Huzzah CC3000 wifi shield. But with the right library, my code should work with any of the wifi shields. I had to order a bigger power supply, though, as the one I had couldn't deliver enough power to drive the wifi.
TwinDad I and my genuine Arduino Wireless shield are awaiting your finishing the WiThrottle code ....... hopefully this shield will work as well without power issues. Steve
Hi Bill, sorry you are having problems getting the trains to operate. A few things to check: 1) make sure the voltage for your external supply is large enough to drive your trains. In N-scale you'll need at least 12V and I typically use 15V. For HO, you may need at least 15V if not 18V or more. 2) Though the Controller may seem to be responding to the throttle, it will do so as long as the Base Station is operating correctly, but this does not mean that the signal is getting through to the tracks. Double-check that you have jumped pins 10 to 12 (for the Main Track Signal) and pins 5 to 13 (for the Programming Track). Are you using an Arduino Motor Shield or something different? If you short the two tracks together and this triggers a circuit-break in the Controller, that's a good sign that everything is at least connected correctly (and that voltage is indeed getting to the tracks). 3) Are you changing the cab numbers in the throttle control interface to match the addresses on your locos? You can either alter the Controller code itself, or "right-click" on a cab button and the interface will allow you to alter the address interactively. If the programming track seems to be working, you may want to try reading the address from the controller's "programming track" screen. One thing to note is whether the cab address is set for long or short mode. The Base Station automatically chooses short-mode for addresses less than 128, and long-mode for addresses 128 or greater. Probably safest to set the address to something 4-digits (like 1234) to ensure you are using long-address mode.
Gregg, thank you for a most complete reply. It was me, and my lack of general DCC knowledge, that I did not get my mind around the fact that loco addresses are held within the Controller-Master, and need to match the encoder address! Programmed the decoder to match and all works well. This is one of those exceptional projects, well documented, and capable of delivering a working layout from easily obtained standard modules at minimal cost. Good luck, and I hope that many people have a go with DCC++
Gregg, This is a truly outstanding project. I have read the entire thread at least three times and watched the videos twice. Just putting this together for a new HO layout build. It's my first foray into DCC. I have VERY limited programming skills. I have built several Arduino projects over the past few years - built as minimalist Atmega 328P boards. I'll date myself – I started my electronics building Heathkits, 6L6 vacuum tubes were the big things on my first monaural Hi-Fi amplifier. So, Scott, I have a Pololu Dual MC 33926 Motor Driver Shield and a Mega 2560. I'm ready to proceed. Looking back at Gregg's post #71 on Oct. 31, are the modifications to the Pololu board shown still necessary with the latest software changes? I have cut the #10 trace and placed a jumper between pin 4 and 13 as suggested in the video published Nov 15. David Ulmer
Yes...I would still use the jumper.....I have not switched to the mega board yet as I am still very much experimenting with the Uno board. Make sure you have a powerful enough power supply. So far my operations are proving very well.
Gregg and TwinDad, Gregg: you mentioned about saving the Function options for example turning the lights on and then the bell...since the Base Station isn't able to save them...how are you saving them in the controller program? TwinDad: same question...how is JMRI saving the options? Thanks for the answers.
David, sorry for the late reply. The mappings when using the Pololu MC33926 with the Mega are different than when using it with the Arduino since the DCC signal generation on the Mega occurs on different pins (12 and 2) than on the Uno (10 and 5). It turns out that the mappings are a bit easier, though since you already cut the trace 10 connection, you'll need to solder that back in place with a small jumper wire, since that actually needs to be connected for use with the Mega. Note that since the Pololu offers a lot of re-mapping possibilities, there are many solutions that will work. The one I recommend is that which requires the least modification to the board and minimal soldering (so the board can be used elsewhere if needed). Previously, I uploaded a JPG that shows the mappings for the Pololu used with the Uno. I added a second page that now includes mappings for the Mega, and instead of a JPG file, exported to a PDF (since it's now 2 pages). Please see the attached file -- the second page contains my recommended mappings for the Pololu/Mega combination. The changes should be straightforward. First, you'll need to solder a jumper wire back into trace 10 since that needs to be connected. And instead, you'll need to CUT the trace for pin 12 (as shown in the diagram). This is because the Pololu produces a diagnostic output (labeled SF) that feeds into pin 12. We don't need to read this diagnostic, and it would interfere with the generation of the main-track DCC signal which is on pin 12 for the Mega. Second, you'll need to insert (not solder) jumper wires connecting pins 12 to 7 , and pins 2 to 8. These are similar to the jumper wires used in the Uno, but reflect the fact that DCC signal generation is now on pins 12 and 2, instead of 10 and 5. Third, you'll need to ensure pin 4 (labeled D2) is pulled HIGH. This is accomplished with the last jumper, which is the same as the one needed for the Uno. That should be it for the wiring. However, there is one change you will need to make to the software. I will add some logic to the Base Station code so that the mappings change automatically if the user selects the Pololu Shield AND the IDE detects the use of a Mega. At present, it assumes an Uno. But before I change then code, it would be good to make sure this all actually works. So in the interim, please change line 71 (which is under the section labeled POLOLU MC33926, NOT the similar line under the Arduino Motor Shield section) in the file DCCpp_Uno.h from: Code: #define SIGNAL_ENABLE_PIN_PROG 11 to Code: #define SIGNAL_ENABLE_PIN_PROG 10 This reflects that fact that the enable pin for the programming track can move to pin 10, which is where the Pololu expects it. When we were using the Uno, we had a conflict with pin 10 and needed to move this to pin 11. If this seems to work once you've tested, I'll update the code to automatically make the change. If not, we can debug and figure out next steps based the symptoms. Please let us know how it goes!
A word about Ethernet Shields: As previously described, I've successfully used DCC+ with a Mega and the Seeed Studio Ethernet Shield. You just need to first download the library from Seeed Studio (a link to the library is embedded in the Config.h file), and then use the Arduino's IDE to "install" the library. However, after I re-assembled all of the electronics under my layout I found a minor annoyance using the Seeed Studio Shield: It does not properly initialize upon power-up of the Arduino. This means after the Arduino is powered, you need to reset it, using either the reset button on the Arduino, or the button on the Seeed Studio Shield. Neither of these buttons are conveniently located, since the Arduino is buried under my layout. A detailed search on the web revealed that this is indeed a known issue with a variety of Ethernet Shields --- the problem is that most shields do not contain a separate reset circuit that initializes the board properly upon power-up. I then searched for ways of resetting the board through software, and there seems to be a number of possibilities, such using the timer watch dog circuitry of the Arduino, or forcing the RESET pin low. But a number of users cautioned that these methods are not always reliable, and the time watchdog circuit is not compatible with the boot loader and the Mega (and if you use it, you may wreck the boot loader). But I was able to find that some new Ethernet Shields DO contain an internal reset circuit and will initialize properly upon power-up. Yesterday I purchase an Ethernet-2 Shield from Microcenter ($39.99). This shield is produced in Italy by Arduino.org. This is different from the original Arduino.cc. The former is a spin-off of the latter run by one of the members of the original Arduino team, and unfortunately there seems to be a lot of competition, and even a legal battle over trademarks, etc. Both Arduino.org and Arduino.cc produce similar boards, and I found Microcenter carried a selection from each. Since I could not find any info as to whether the original Ethernet Shield from Arduino.cc contained a proper reset circuit, I went with the Ethernet-2 from Arduino.org. It works great! You just need to download the library and "install" it within the IDE. I included it as an option in the Config.h file, along with a link to the Arduino.org GitHub site. You unfortunately need to download the entire Arduino.org repository just to get the Ethernet-2 library. This is because Arduino.org is also producing its own version of the IDE. I didn't want to install a second IDE, so I just used the original IDE and "installed" the library from the new IDE folder. In principle I can add these libraries to the DCC++ GitHub repository, but I'm not sure I like the idea of including external code in the repository since the libraries might be updated and the repository versions would get out of sync quickly. In addition to updating the Config.h file to utilize the Ethernet-2 library, I also made a few other minor changes. First, I fixed a problem in the short-circuit routine when used on the Mega that was introduced when I switched the signal generation from Timer-0 to Timer-3. It had to do with how milliseconds are computed on the Arduino and thus the timing I was using between sampling the track-current. The Arduino millisecond logic utilizes Timer-0, and is affected by any changes to Timer-0 settings. In DCC++ for the Uno, we use Timer-0 and thus it's settings were changed. The short-circuit routine was tuned to reflect the new settings. But since the Mega does not use Timer-0, its settings are not changed, and the short-circuit code needs to use a different sampling period to obtain the actual same frequency. This explanation is much, much, longer than the actual code change, which is only three lines. The second change has to do with the order in which setup events occurs. Previously, the Ethernet Shield would be initialized, then the EEPROM was loaded, and then the Arduino printed a message to the SERIAL port (even if Ethernet was chosen) showing a simple status message, and an <N> command indicating the communication protocol being used <N0> or <N1>. The problem with this order is that if the Ethernet is not yet ready, it appears that the Arduino is hanging. So I changed the order so that first the EEPROM is loaded, then a simple status message is printed to the SERIAL port, and then the Ethernet is initialized, after which the <N0> or <N1> response is printed to the SERIAL port. -Gregg
I store the individual functions in an array that are tied to my function buttons. Then, whenever I hit a function button, the code notes which range the function is in (F0-F4, F5-F8, F9-F12, F13-F20, or F21-F28) and selects the seed for the first byte to the <f> call. It then uses the formula shown in SerialCommand.cpp to either (a) add values to the first byte, or (b) create a second byte. Then it makes the <f> call to the Base Station. The Controller code also has a bunch of logic that keep track of functions that are operated simply through a change-of-state in the decoder. For example, bell, horn, and light functions are usually either on or off, so it makes it easy to keep track. But one-shot functions, such as a coupler sound, or an airbrake sound, etc., are activated on most decoders whenever the state is CHANGED from either on to off, or from off to on. In DCC++ Controller I need to have additional logic that simply toggles the state of these types of functions from on to off, or from off to on, when the user triggers them. -Gregg
