Gregg, Thanks for the reply and helpful information. I was able to do the hardware modifications easily although the trace on #12 was difficult to cut. My meter showed continuity at first attempt, but is now correctly severed. Changed the software line 71 and the baud rate on the Arduino to the correct value. Powered the motor shield with 12 volts (I'll be using a 20 volt power supply when I connect the tracks) and the Arduino with USB. The program compiled, but serial monitor said Mega board with Arduino shield. I went into config.h and changed line 17 to 1. At this point I expected the program would compile and I would get the Pololu shield notification. Unfortunately it did not compile, so I surmised that I needed to add the Pololu library. The Arduino IDE did not like the zipped file. I unzipped it and dragged the folder to the Arduino library. Got an error that it was not a valid library. At this point I deleted the files and decided to reload the Arduino program. Seems we have a new version 1.6.7. Anyway, without the Pololu library, the program uploads and I get the correct readout on the serial monitor . I don't have track hooked up at this point and don't have a loco with a decoder installed yet (hopefully that will be remedied by bedtime tonight!) . With the shield and Mega powered and running the program, should I be able to measure voltage at the outputs for the main and programming tracks? What else to do now? David
David, it seems like things are working so far. You do need the latest version of the Arduino IDE to make sure the conditional #includes are handled correctly. You should not use the Pololu library - it is only needed for standard motor shield work (to control motors), but not by DCC++. If the shield is powered and you are communicating via the Serial Window, issue a <1> command to turn on track power. If you now measure the voltage at the Pololu outputs (with voltmeter set to AC), you should see approximately 12 volts. If so, you are getting a DCC signal! To turn off, issue a <0> command and the voltage should be back to zero.
HI Gregg, Seems I'm communicating with serial. I have downloaded the latest Arduino IDE today as well as both of your updates. I went in and redid the software changes on line 71 in DCCpp_Uno and line 17 in config.h after updating your programs. I get 12 volts DC input to the motor shield and only 0.075 volts AC or so on the outputs. Here is what shows up on the serial monitor after sending <1>, <0>, <1>: <iDCC++ BASE STATION FOR ARDUINO MEGA / POLOLU MC33926 MOTOR SHIELD: BUILD Dec 20 2015 17:12:37><N0: SERIAL><p1><p0><p1> On the controller screen I get an error message at the top – Serial Port Busy: /dev/tty.usbmodem1431 Does this help? Am I doing something wrong? David
Looks like you are correctly communicating with the motor shield through the serial monitor. Note that you can't have the serial monitor and the Controller programming running at the same time --- the Arduino only permits one serial connection at a time. Provided that the serial monitor is not open, when you first start the controller program it will try to connect to the Base Station. But it does so by remembering the last serial connection used, which if you just downloaded the software, will actually be the serial port name used on my machine. To find the serial ports used on your machine, hit 's' in the controller program and it will bring up the serial scan window. Press the scan button and it will identify all available ports. Use the arrows to choose which port your Arduino is using, and then hit connect. You may need to use a bit of trial-and-error since the names of the ports are usually cryptic. Once you select the right one and hit connect, the controller should indicate it is communicating with the Base Station by echoing back the status message at the top of the screen. You should then be able to toggle the power on and off with the power button. Before connecting the arduino to the pololu shield, make sure that the pin 12 trace is fully cut since that's where the main dcc signal is generated. With the power button on the controller lit, you should be seeing voltage on the main output pins of the shield if all the jumpers are correctly connected.
Success!!!! It was the trace at 12. I thought I had cut it - obviously not. I now have lights beside each output to the tracks and 12.74V AC on each. I can communicate with both the Controller and with the Arduino Serial monitor. Now I need to get the locomotive ready and see if I can program the monster. This is exciting! David
Gregg, I figured out how to save the options dynamically....I'm going to test it out and report back...basically saving everything in a Hash array and checking the state of each function
I am a novice in this group and I have been following this project which looks excellent, 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), with a motor shield drive by a dual full-bridge L298. This 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. Just now I am looking for a new power source transformer.
If you are running HO Scale trains I recommend a power supply similar to the one I am using which is from a digitrax DCC package...it can handle HO/N/G scale trains....18-26 volts and it has been working quite well.
I think He's asking how JMRI stores the last known value(s) of switches, lights, etc. before DCC++ power down so to know what they are at next DCC++ power up.
I can't recall offhand what happens when you have a panel built, but I don't believe it stores prior state at all, at least at the basic level. On boot, everything is set to "unknown" state until either the user or the base station does or reports something that creates a known state.
That's true for my panels. Switches and sensors are set to unknown. I have a single switch that sets all the other switches to normal and the sensors resolve their state when they report a change of state.
Actually I was asking more on the throttle side of things....how does the Java Controller and JMRI remember the states of sound selections for example: If you have the locomotive lights on and then issue a command to turn the bell on/off it also turns the lights off....I did solve the issue as I had to look for "state" in other words my GUI controller I made saves the option "lights on" then issues the byte code to keep lights on while turning the bell on/off and so on.
Bill, I have the same problem as you. No movement of loco. My question is, how to program the decoder instaled in my loco? Could you help me? Regards
I'm still confused... why would changing the bell state affect the lights? Are you saying there's a bug? It sounds like maybe the GUI (or JMRI) is miscalculating the function command byte(s)... hitting one function button should not affect any of the others...
The core of the issue is that DCC groups functions together (F0-F4, F5-F8, etc) and if you want to activate, say F3, you need to send a command that specifies everything in F0-F4, even if you don't want anything to change in F0, F1, F2, and F4. There is no workaround for this since it's the way the decoders work. Also, there is no method of reading the state of a function in a decoder since functions are not stored as CVs. This is a real shortcoming of the DCC standard. Even trickier is that many decoder functions are neither ON or OFF. Rather, they are "activated" for a short period of time (such as a sound FX) when whatever state for that function stored internally is switched from either ON to OFF, or vice-versa. This is something decoder manufacturers came up with and is not part of the DCC standard. Unfortunately, DCC has no command that says "toggle" the state of a function (which would be very helpful). And that means that if you want to activate this type of function, you need to first know what the state of the function is within the decoder, which is not possible unless you force the state in one direction (ON or OFF) and then save the state in software so that you can keep track of whether you need to send an ON command or an OFF command the next time you want to trigger the function. Also, on power-up of my locomotives, there does not seem to be any standard or consistency with the initial state of the functions (which also would have been very useful). In DCC++ there are two places we could keep track of the state of the functions -- either in the Base Station or the Controller. In commercial DCC systems (well, at least the one I used), the command station simply supplies the power and the DCC signals, whereas the throttle contains all the logic for sending functions, controlling speeds, etc. Since the Base Station is supposed to be the analogue of commercial command stations, I kept the function logic to a minimum and decided to create all the necessary logic in the Controller. However, there is no reason why that same logic couldn't be added into the Base Station as well, in which case if you were running multiple throttles, they can share state information. The only thing that would not be useful is to store the value of functions for each decoder in the Arduino's EEPROM for saving between power cycles --- this is because when the decoder is powered up again, the state of the functions are not necessarily what they were before power-down. A workaround for this would be to "initialize" each loco on start-up by sending all OFF values to each function (which may result in triggering certain functions in the decoder if they woke up in an ON state). Adding function logic to DCC would not be too difficult but I'd really want to think through the most efficient framework. This is because the logic would need to be stored on a per-cab basis, and the Base Station has no concept of cabs. It knows about throttle commands and stores those in packet registers, but it's not really "cab-aware" and different registers can even contain conflicting throttle settings addressing the same cab (fun to do, but not really recommended). In contrast, when you send a function command in DCC, this is a one-shot request (technically not true since the same function-request packet is sent 4 times in a row --- repeats are recommended by the DCC standard, and decoders only perform the function once). The packets are not saved in a register but simply tee'd up for immediate processing and sent to the tracks. So there presently is no natural place to store cab-based function data. Since we would have to make one, we should think through what other cab-based information we may also want to store so that it can be built in the most efficient and general manner.
I'm not too worried about storing the functions on a power up or down phase except for MU consisting....if the lights, bell, or horn are off on power up thats fine...my main question was how did your Java controller and JMRI know to keep the lights on when you issue the horn or bell command since you have to send one byte string at a time. In other words....the program remembers the lights are on and then ring the bell.....if you just issue the bell command the lights will turn off and vice versa. In order to see what I am talking about: open up the Arduino serial monitor and issue the <f locoid lightson 1> and then issue the <f locoid bellon 1> command and then issue the <f locoid 128 1> command and you will see it all turn off as the 128 is the all OFF command instead of just turning off the bell. I hope I explained myself clearly.
You have to issue the locoid command in order to get the loco to move <t 1 locoid speedstep 1> in other words <t 1 03 20 1> this would make loco address #3 move forward.
