My understanding is that they are Test versions and a Production version of 4.3.x is due out in Mid 2016. So for our testing purposes is DCC++ supported on JMRI 3.1.1 and 3.1.2? I only asked because the JMRI Site says "NOTE: DCC++ Support only works in JMRI 4.1.5 (for now). Do not use 4.1.6 or 4.2.0 with DCC++" http://jmri.org/help/en/html/hardware/dccpp/index.shtml#Limitations Kevin
JMRI releases follow a pattern... Odd numbered release (4.1.x, 4.3.x, etc.) are development releases... there will be as many of them as necessary during a development phase. Even numbered releases (4.0.x, 4.2.x, 4.4.x, etc.) are Production releases. These traditionally come out every six months, just before Christmas and (traditionally) at the NMRA National Convention in July. Usually the production release stops with the N.N.0 release, and incremental releases of a Production release (e.g. 4.2.1) contain only critical bug fixes. There will be a string of 4.3.x releases all winter and spring, culminating in 4.4.0 at the NMRA Convention. As we get close to releasing 4.4.0, the rules for what can get checked into the code get very tight, to make sure the code is as stable as possible before creating the Production release. Immediately after 4.4.0 is released, all the stuff that got deferred during the lock-down phase will be released as 4.5.1, and the cycle will repeat in preparation for 4.6.0, the next Production release. Since 4.3.1 and 4.3.2 only just came out I have not had a chance to update the documentation (been busy at work). Here is the history: 4.1.4 had the very first, very basic support for DCC++ ... 4.1.5 had the first reasonably full function support 4.1.6 I tried to fix some things and ended up completely breaking support. 4.2.0 came out before I could fix the bugs introduced in 4.1.6 4.3.1 contain the bug fixes for 4.1.6, plus a couple of other bug fixes that I was alerted to. 4.3.2 and following 4.3.x releases will contain further improvements and bug fixes. 4.4.0 will come out in July and be the next stable production release. If you are using DCC++ with JMRI, I would definitely recommend moving to 4.3.2 and keeping up with further 4.3.x releases (assuming I don't break something again). The 4.3.x releases will generally be stable enough for developer types to work from. In particular, the sorts of things y'all will be doing to test out DCC++ functionality will be as stable as the DCC++ code itself HTH
HTH Thank you, This Post will help limit all future inquiries. Very Much Appreciated. Keep up the Great work! Kevin
Thanks, Kevin. I've updated the JMRI documentation to reflect the current state of affairs, so hopefully that will minimize the confusion as well.
Wonderful - success, it works! I'm a bit of an amateur when it comes to coding - I know enough to get into trouble but not enough to get out of trouble! I have only recently started dabbling with Arduino and C+ - the syntax drives me crazy! But I have downloaded DCCpp_Uno to Arduino 1.6.7, DCCpp_Controller to Processing 3, and installed JMRI 4.3.2 Set up an Arduino UNO with a Pololu MC33926 motor shield and a bit of test track. And what do you know - after finally figuring out I needed to change the config.h file, Motor_Shield_Type to 1 for the Pololu shield I managed to get JMRI to talk to the DCCpp base station and to program decoders and to run my trains. I'm blown away by the efforts of Greg to develop this software and Twin Dad to get JMRI to talk to DCC++, so many thanks to all of you for the work that has gone into this. I think this system has huge potential. I have had the DCCpp Controller running on its own, but not driving the DCCpp base station yet. I need to dive into that and find out how to change the cab numbers and then later edit the track layout - I guess if I read carefully Greg's various posts on this I'll eventually figure it all out. I've ordered a Mega so that I'll be able to add more I/O to the system later and get it to start operating turnouts and signals - but one step at a time. I'm also intrigued by the prospect of a simple wireless (not WiFi) handheld walk around throttle that can send serial throttle commands to the base station. I guess this should be possible with the various wireless modules on the market. Much learning still to do. Keep up the fantastic work Chris
This morning I decided the the DCC++ controller needed a proper enclosure. I designed one in Corel Draw and cut it from 1/10" acrylic with my laser cutter. It turned out rather nicely - details and the Corel Draw file are here: http://trainelectronics.com/DCC_Arduino/DCC++/#An_Enclosure_for_the_DCC++_Controller dave
Dave ... not as sophisticated but this is an enclosure I built from a stock plexi box for your original design before we got so deeply into DCC++
TwinDad In replacing Ethernet.begin(mac) with Ethernet.begin(mac,"10.0.0.117") I get errors on compile ...obviously my formatting is incorrect ...... can you amplify on correct code line. Thank you Steve
try something more like: byte ip[] = { 127, 0, 0, 1}; Ethernet.begin(mac, ip); The IP address needs to be an array of bytes (bytes, really), not a string. There's example code near the bottom of this page: https://www.arduino.cc/en/Reference/EthernetBegin
OK so I have set the mac addee and IP as follows: #if COMM_TYPE == 1 byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; IPAddress ip(10,0,0,117); Following this Arduino advice: "Some devices come with a sticker on them showing a MAC address that's been assigned. If that's the case, easy: just put it into the sketch and you're done." (My shield has no sticker) "Mostly though you'll need to make up your own MAC address, and it's important that you create a valid address.Generally, you can just make up an address and it'll work start with this 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED" and I changed your sketch code to: #if COMM_TYPE == 1 Ethernet.begin(mac, ip ); Everything compiles and uploads to the Mega but I get no connection in Engine Driver using: 10.0.0.117 and port 2560 on a cell phone ..... nor can I find 10.0.0.117 in a scan of my LAN I'm begining to think that this is above my pay grade but maybe this feedback will help you move the wireless part of DCC++ along.
So... just making sure... you did change line 32 in Config.h to say: #define COMM_TYPE 1 and line 41 to say: #define WITHROTTLE 1 ... right? Just eliminating the obvious before moving on to the more challenging. The next issue, which is where I'm stuck, is power supply to the wifi/ethernet shield... my WiFi shield (at least) requires at least 1A at 5V power... which is too much for it to piggyback off the Arduino's power regulator... so you (apparently) need to provide an external 5V supply of at least 1A, maybe more...
yes, both COMM_TYPE and WITHROTTLE are set to 1 ......... Engine Driver throws an error that says "can not connect ........ no route to host" I have forwarded port 2560 to 10.0.0.117 in my router but still no connection. First edit: TD .... Just dawned on me that my network is WEP encrypted ... so that is probably one reason that is preventing connection ...... writing code to include that is way above my pay grade
Sorry to chime in a bit late on this, but note that the Arduino Wifi library is similar, but not identical, to the Ethernet library. There are also additional config steps that must be taken to initatilize a Wifi board on a given wifi network. The current version of Base Station includes all the appropriate commands to connect to a network using an Ethernet shield, but does not include anything for a Wifi shield (it's on the list to-do list once I get around to getting a wifi shield). TD, I know you customized a version of base station for use with WiThrottle. Did you include the appropriate SSID init code that would otherwise not be needed for just an Ethernet connection? -Gregg
No. I started to do that but it was... Problematic... Having the WiThrottle code with Ethernet/wifi code embedded especially when we started supporting Ethernet/wifi connections for the DCC++ command interface. So I stripped it all out. The WiThrottle code doesn't care what sort of port it is communicating over. All the Ethernet/Wifi setup should be in the main configuration code. Which probably means one of us should write it ...
Esfeld, Just trying to follow the terminology..... When you say "Mostly though you'll need to make up your own MAC address, and it's important that you create a valid address." do you mean IP Address? An IP is assigned by a DNS like 192.162.0.101 or you can assign a fixed one yourself like 192.162.1.1 along with a subnet mask such ass 255.255.255.0 But a Mac Address is a unique NIC Network Identifier address embedded on the network card by the manufacturer. such as 84:38:38:56:B4:AB and as far as I know you don't want to try changing them. You can use the MAC Address in a wireless router to pre-assign MAC Addresses that are allowed to onto your network all other MAC Addresses will be blocked. Such as a home primary wireless network SSID MYHouse were you know all the PC, Laptops, Printers, phones that are in the house. and a Second home wireless network band for guests SSID MyHouseGuest were you don't pre-assign MAC Addresses but allow anyone with a valid Password to sign on. I Plan on adding a Third wireless network band to mine SSID DCC++Guest for wireless Phone Throttles. I'm probably embarrassing myself by even bringing it up so please don't be offended if I'm off mark with what you were trying to convey Kevin
Esfeld Now that I've ready the context again, I get what your saying I think, on the development code for testing purposes just make up an address and it'll work start with this 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED" It would be nice to read and capture the Arduino Wireless Shield or Ethernet Shield's Mac addresses like we do in Dos 'ipconfig /all' and load them into the program. I'll back out the door bowing now....... :^) K
Nope... he means a MAC address... Yes, but... some of the Ethernet and WiFi shields don't have any documentation with their MAC address... and they don't provide a way (or at least not an easy way) to retrieve the MAC address from the hardware... Fortunately, re-using some other device's MAC address is only a problem if they are both on the same subnet...
Progress report: Mega 2560, Pololu shield, 19.5vdc laptop power supply, JMRI 4.3.2 over USB, HO loco = working. Woohoo! I did a short circuit test. The only way I found that I could recover after shorting the Main was to power-cycle the motor shield. A reset of the Mega didn't do it. Is this expected behavior? Note - I am using the 'board enable' shunt on the Pololu shield rather than the jumper from pin 4 to VDD. I have found that removing/replacing the shunt also will recover so I don't have to do a full power cycle. I haven't tried to dig into the code, yet - does it do something with pin 4 and so I should be using that jumper instead of the shunt?
