That's correct - for the Mega you should only need one jumper wire to connect the Prog Track Signal (pin 2) to the Motor Shield Direction Channel B (pin 13). The Main Track Signal is already produced on pin 12 which matches the Motor Shield Direction Channel A. Also, you can ignore those warnings from the compiler --- they will not affect the operation (and you turn them off by de-selecting the verbose option in the IDE).
That's great news. Also, note that you can interactively change the cab numbers within the interface by right-clicking on any of the cab buttons. I hope to expand this functionality in the future so you can dynamically configure all of the cab functions, and have all of the settings saved in the XML file.
Hello Gregg, All is well with my DCC++ setup at the christmas train show...I've even demo'd to several club members and they were like...wow....you mean I can do DCC with out the use of my purchased DCC system? I said yes at a fraction of the cost! My GUI throttle works well too....I still need refine the commands for sound function other than that it works wonders. I also have a simple signal system setup too...this is one of my own design for Arduino....it is separate from the base station as I am still a strong believer of keeping everything other than DCC signals/commands separate from signals and other accessories. One less thing to go wrong. Now I am working on a module that will allow you to use any DCC manufacturers hand held controller to control trains using the DCC++ base station outside from having to have it connected to JMRI....I just needed to figure out each manufacturers priority in sending commands...its not all the same...this is how it becomes...proprietary...as in how each manufacture deciphers and controls DCC packets.....more to come on this later as it develops.
Gregg/TwinDad I have had a working DCC++ system working since page 11 of this thread (thank you) but stopped there since I don't use sensors etc etc. I am now using DigiTrains on an Android tablet interfaced to JMRI on a laptop very effectively ....... have you guys done any development of a multi throttle interface (other than WiThrottle, since I am not in the Apple camp and use Android) directly to DCC++ using a WiFi shield so that one can eliminate the laptop (JMRI) and directly control DCC++ from any WiFi enabled device? Steve
The WiThrottle interface supports both WiThrottle (iOS) and both EngineDriver and DigiTrains (Android). It's just named that way because the WiThrottle guys came up with it first and EngineDriver used the same interface (or at least I think so). Anyway, the interface is not iOS specific. Only the app is. My WiFi shield is due to arrive tomorrow, so I should be able to get the WiThrottle/EngineDriver/DigiTrains interface tested this week.
I downloaded the zip again just now from https://github.com/DccPlusPlus/Controller -- I get "Component Name: NAME NOT DEFINED" error. I can see code in dCabs: " void rightClick(){ editWindow.open(); } " Must be some disconnection between control-click and being recognized as a right-click. David
Yes, the two-finger tap is the one. It is interpreted by Procesing as a right -click. Control-click is also used by the code: it echoes back the name of the component you are selecting, if that name has been defined. If not, it just says no name as you have seen. It's useful for finding the name of a turnout or sensor so that you can identify it on the code to make changes.
Yes, that works, and let's me change the DCC address on the button --- much easier than modifying the code! David
First off, let me thank and congratulate all who are actively developing this (esp. Gregg and TwinDad) I'm very excited about the prospect of operating in this mode but have so far been frustrated by what I believe may be hardware issues (?!) I've downloaded the latest sketch and put together a DCC++ base station using an original Uno R3 and Arduino branded Motor shield; the required jumpers are in place to connect timer counters to the DirA and DirB pins and Vin has been separated to avoid overpowering the Uno. The UNO is powered by my Win8.1 laptop while a 12V 1.5A regulated power supply is connected to the motor shield. The sketch has compiled properly and downloads successfully; I'm connecting alternately with the latest JMRI test build (with DCC++ support) and Gregg's Processing sketch. The Arduino serial port is configured at 115200 and FlowControl is disabled for the JMRI connector. I'm able to communicate successfully and turn on/off the power to the "track" => outputs A and B. But.... - every time I read a "sheet" in JMRI or individual CV's in the Processing app the value "FF" (255) is returned for virtually all CV's (even CV1 which I know is currently 3). - every time I try to write a value I get timeout errors between the application and the controller. In JMRI these show up as error 306. In the JMRI message log, I'm seeing many lines to the effect: 2015-12-09 21:48:45,816 dccpp.DCCppReply ERROR - Malformed Validator Command: r 0 82 29 255 pattern \s*Q\s*(\d+)\s+(\d+)\s+([0|1])\s* [AWT-EventQueue-0] 2015-12-09 21:48:45,819 dccpp.DCCppReply ERROR - Malformed Validator Command: r 0 82 29 255 pattern \s*Q\s*(\d+)\s+(\d+)\s+([0|1])\s* [AWT-EventQueue-0] 2015-12-09 21:48:46,528 dccpp.DCCppReply ERROR - Malformed Validator Command: r 0 82 17 255 pattern \s*Q\s*(\d+)\s+(\d+)\s+([0|1])\s* [AWT-EventQueue-0] Any thoughts? I'm afraid I'm at my wit's end. Thanks in advance, Michael
Yeah, um... I ran into this too. You have to have a motor shield that supports current feedback in order to read CVs. In DCC, the decoder talks back to the command station by generating short burst of current, literally by briefly running the motor. You may have noticed your locos creep along the programming track in short bursts when using other systems. Unfortunately, the Arduino motor shield does not have current feedback, so the Base Station is unable to "hear" the decoder's response. You should be able to operate the train just fine, but you'll need a different motor driver board to do reads. As for writes, I think the decoder is supposed to generate a short "Ok" burst in response to those as well, but I can't recall for certain. I'd have to go check the NMRA standard for that. Oh, and you can pretty much ignore all of those "Malformed Validator" messages. That's just the command parser trying different types of commands to see which one it has received. I have downgraded that message to "debug" instead of "error", as it really isn't an error at all.
Really !? But I'm using the same motor shield Gregg uses in his video series (the genuine Arduino one). Also, I'm getting the timeout errors returned from both JMRI and the Processing Controller on writes.... Michael
I've been following this thread with interest. It's great to see an inexpensive alternative to the commercial systems. Thanks to those developing it. If you have a MicroCenter store near you, it looks like they've got a sale on their house brand clones of the Uno ($6) and the Mega ($10). Here's a list of their locations (scroll down to the bottom).... http://www.microcenter.com/site/stores/default.aspx Steve S
The Arduino Motor shield definitely has the current sensing circuitry - it's connected through pins A0 and A1, so that can't be the problem. To begin, Michael can you confirm that the operations track is working correctly, and that you can control the train throttle, lights, etc. I'm unfamiliar with JMRI so you may to confirm this using the DCC++ controller to start. If this is not working, then something much bigger is wrong that's unrelated to the read/write functions. If all the operations track functions are working, then there are number of other potential issues. The first is that I inadvertently messed up the Uno signal generation for the programming track when I updated the software last week to make it generic for both the Uno and the Mega. I will throughly test this with the Uno this weekend to make sure the signals are all where they are supposed to be (with pin 10 jumpered to pin 12, and pin 5 jumpered to pin 13), and that I can write and read CVs. If I find any problems I will fix and post an update. If that's not the issue, it's probably something in the logic that tries to determine if a current spike is sent from the locomotive when a read command is invoked. What scale train are you running? The calculations used for reading the current were calibrated based on N-scale engines and decoders. It is possible that this needs to be tweaked for HO-scale. The other issue may be the track voltage. On my system I use 15v for the tracks, and the current calculations are calibrated based on an engine's responses with 15v of track power. Since you are using 12v, a recalibration to the logic may be needed since the current the calculation needs to sense would be much less, and possibly less the the threshold used in the code. I can test this as well by switching out my 15v supply for a 12v supply. If I do see a difference I'll try to generalize the calibration, or make track voltage a user-definable parameter that modifies the thresholds. Note that commercial base stations generally come with their own power supply so that the circuitry used to read current spikes is already tuned for the correct voltage. And in fact some commercial base stations have a switch to change the output voltage, which would likely also change the way the current is sensed. Will be an interesting experiment for this weekend. Also, can you try writing to a CV from the main operations track. I know you can't read CVs from the main track so you may have to be clever with which CV you change so that you can determine if it was indeed written. Maybe something that changes the headlight from steady to blinking? I'm a bit puzzled by the timeout errors you are getting during a write command. This is because I don't think I programmed a time-out error message into either the base station or the processing code. In the processing code, is the error coming from the interface, or is it in the console below the interface (i.e. an error message from processing itself). Note that a return value of 255 is consistent with no current being detected, so unfortunately it doesn't hint at what might be he problem. Michael, any info regarding the above questions that you can provide before the weekend would be very helpful since I should have time this weekend to explore further.
I stand corrected. JMRI is simply generating the command messages and interpreting the responses. I've seen the "255" thing with my SparkFun motor board (which definitely does NOT have current sensing), which is why I assumed that is what is wrong with the Arduino driver (but I'm mistaken). Definitely debug with the Processing tool, or perhaps better yet by hand-generating commands in the Arduino Serial Monitor. JMRI does have timeouts, and I have not optimized them yet. I would expect you can safely ignore them. Even with the timeout, JMRI will re-send the message up to 5 times while waiting for a response.
I will try that tonight..... I'm guessing I wouldn't be the first person to experience issues if that were the case .... I'm running HO scale; I will also try with 15-18V this weekend. To be sure, the 12V had occurred to me too but I hadn't had time to test this yet. Sure, I can come up with something.... The error I receive is in the processing console top bar (in red) where I'd normally expect to see the green acknowledgment.... Gregg, Thanks so much for all your help; I will try to perform these tests and get the information back to you as quickly as possible.
Thats one thing I haven't tried in HO Scale yet is to program anything using the Pololu motor shield.....it seems I am the only one here using this system in HO Scale? Correct me if I am wrong.
Michael....I am using a digitrax 18-25 volt power supply and I've been using DCC base station with a Pololu Motor shield which is capable of handling the larger voltage.....the Arduino motor shields do not seem to be able to handle the larger voltages. I made my own GUI throttle for the base station and so far all is working nicely....I did not try any programming yet as I tend to use th QSI/Lok Sound programmers.
