I'm not sure but i believe you need it to look like this: #if COMM_TYPE == 1 byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; byte ip[] = { 0x0a, 0x00, 0x00, 0x75 }; /* this is the same as -> (10,0,0,117) only in hex 8-bit as a unsigned char, or a byte if it was 192.168.1.10 it would be 0xc0, 0xa8, 0x01, 0x0a */
The compiler doesn't care whether the IP address is in hex or decimal (as long as they represent the same value), only that it is an array of bytes (not a string). The MAC address could be specified in decimal to, it just isn't because it's usually written in hex by convention. Again, the compiler couldn't care less. Aside from that, you're absolutely correct.
Hi Mike, I believe the Pololu has its own short circuit protection built in - the symptoms you are describing imply that the Pololu's protection is kicking in before the software short circuit protection. That is fine but as you've found, the software as currently written can't reset the Pololu if the board's own protection kicks in. DCC++ recognizes enables for each channel of the motor shield and can turn those on and off. But the Pololu has a third board-wide enable tied to pin 4. Originally, rather than add additional logic to control this pin, I recommended that pin 4 simply be tied high permanently. This can be done either with the shunt or by jumpering pin 4 to Vdd. The shunt basically connects pin 4 to Vdd for you. What you've identified is a reason that we need to be able control pin 4 in software - it needs to be reset (e.g set low and then again returned to high) in order to reset the Pololu if the Pololu's built in fault detection is triggered. One way to do that is cycle the power on the Pololu. The other way is removing and replacing the shunt, or removing and replacing the jumper wire connecting pin 4 to Vdd (if that was used instead of the shunt). Resetting the Mega does not reset pin 4 since it's physically tied high. Here are a few solutions we can consider. The first is to add some logic to DCC++ so that there is a master enable tied to pin 4 when using the Pololu. The second would be to have pin 4 controlled along with one of the other enable pins - either the pin for the main track enable or prog track enable (doesn't matter which). You might want to give this a try: Remove the shunt, and instead jumper pin 4 to either of the track enable pins. Now when the board protection kicks in you should (in theory) be able to reset it by simply issuing a <0> command (which will bring pin 4 low) followed by a <1> command. If that works we can update the docs to recommend this method. Note there is also a way of detecting if the Pololu enters a fault state. However, that would require DCC++ to monitor an additional pin (which might be a good idea anyway). Let us know how it goes. -Gregg
David and Gregg, Same problem of only Programming track getting power --- "Problem Identified" Solved. SurfacePro3 Windows10 to USB power (6.5vdc) to Inland Arduino UNO Rev3 $5.99 and a Original Arduino Motor Shield $4.85 with a wall wart 15vdc 1amp power (DCC++ Base Station 1.6.7) Configured UNO pin outs (5 to 13 and 10 to 12) and disabled Vin on Motor Shield as directed. Uploaded DCCpp_Uno Successfully using com 6. Check Config.h all good Opened Serial Monitor at 115200 baud <1> turned on Motor Shield power ok <D> started Diagnostics ok (brilliant piece of work Gregg :^) Programming LED's fast alt blink, Main LED's slower alternate blink still AOk I was getting a DCC pulse on both track. But I was getting power to the Programming track >20vac but not the Main track <.001vac> Checked the voltage directly from the first 15vdc rated wall wart plug, it was putting out 20.1 vdc.. Replaced it with another Wall-wart 12vdc 900ma that shows 16.5 vdc at the plug. Pressed reboot button on both the Arduino UNO and the Arduino Motor shield plugged in the second 12vdc-16vdc with 900ma power and now Both Main (15.5vac) and Programming (14.7vac) track have Power. Tested Shorting both the Main and the Programming track separately and both shorted at the Motor Shield and restarted on throttle power button. Note; I have a PM-3000 AC/DC Rectifier board on order to convert a MRC 18.5Vac 3amp transformer to 18vdc, 9vdc and 5vDc. which I plan on using to power the Motor Shield Another HO scale DCC++ SUCCESS!!! SurfacePro3 Utilized JMRI 4.3.2 Decoder Pro Panel Pro Throttle - entered 1225 address pushed Power Button and 1225 Pere Marquette 2-8-4 Steam loco Fired Right up!!!!!! Whistle, Bell sounds, Forward, Backward all worked! Man I Can't stop SMILING 8^) !!! Will do some more testing various PanelPro Throttle functions. Then later see if I can get JMRI EngineDriver to work via Galaxy S5 Android and a home Ethernet Wireless network. Gregg you and the DCC++ Team are Awesome! Keep Up the Great work. Kevin
Kevin If you can get Engine Driver to work via S5 on your network .....Genius!! Please let us know how. Steve
Steve, Ditto on getting the Enginedriver running. I did startup JMRI Web Server and was able to run the DCC++ BaseStation and my Engines through FireFox web browser. It uses Jason Simple Throttle utilities. very archaic don't know why you would want to do this Moving up and on to JMRI EngineDriver via a Ethernet wireless connection............. Kevin
Guys the EngineDriver stuff through JMRI should be literally as simple as clicking the "Start WiThrottle Server" from the Actions menu in DecoderPro (Debug menu in PanelPro). There are some preferences settings in the WiThrottle tab of the JMRI Preferences window if you need to change the port number to some fixed value, but you probably don't even need to do this.
Ok Success On Engine Driver! Using a Samsung Galaxy S5 with JMRI EngineDriver 2.11 and Arduino Uno/Motor Shield w/ DCC++ Base Station 1.6.7 to run my 1225 2-8-4 Berkshire HO Steam engine .... toot toot.. all Sound Forward, Reverse, Lights etc... Via a Asus Wireless Ethernet Router on 5Ghz band. fast response This is Tooo Fun . Kevin
You think that's fun... wait till we get the WiThrottle/EngineDriver support built directly into the BaseStation...
Kevin/TD Concept confusion ..... yes we can all run wireless with a computer or laptop running JMRI/Panel Pro over a network ......... what I thought we were trying to achieve was wireless from an android device (phone/tablet) running Engine Driver to an Arduino setup consisting of an Uno or Mega with a Motor shield and a Wireless/ethernet shield ....... making a self contained DCC++ wireless controller ....... no computer needed. ......... the picture I posted earlier on page 31 of a plexi enclosure using Dave Bodners controller (using a TV remote) does just that ....... but it aint DCC++ ! Steve
We're getting there. Patience... one step at a time. There's (at least) three ways you can set this up, each with their pros and cons: 1) WiFi Shield direct to smartphone: Most compact, self contained implementation, but resource intensive on the Arduino and most of the WiFi shields I've seen have a limited number of clients they can simultaneously service. Also, possible limitations on range for the WiFi shield. 2) Ethernet shield to wifi via a WiFi router, to smartphone: Slightly bulkier, but the Ethernet shields cost less, and the wired connection is inherently more reliable. Of course, you have to be able to cable to your router. 3) WiFi, Ethernet or Serial connection to a Host PC running the WiThrottle/EngineDriver server. This is obviously the bulkiest and most expensive route (though a Raspberry Pi would do a good job for little cost and not much size), but offers the most horsepower for serving the most smartphone clients, and also the best opportunities to secure the wifi connection, given the added horsepower of the host machine. #3 is also the easiest to implement and is already "DONE". This is what Kevin has implemented. #2 and #1 I have test code in my github repository (https://github.com/msunderwd/BaseStation-Uno under the WiThrottle branch) but I haven't been able to test it due to hardware problems. I'm hoping someone will get it up and running too. Note that you don't have to have a WiFi shield to test this... an Ethernet Shield connected to a WiFi router will work too (assuming the code works at all, and once the bugs are worked out). ETA: Note also that keeping JMRI on a host PC/RPi in the loop also brings the benefits of enabling the turnout/route management and other features in WiThrottle and EngineDriver that we have not (yet) implemented in the Base Station because ... well... I have't figured out how yet...
Sorry Steve Now I understand your focused on a Self Contained integrated Arduino Ethernet shield 'no computer needed'.... It wasn't as clear by reading though the 30 pages of text. ... Thanks TwinDad for Clearing it up in the post above.... I did get a get a chance to build a copy of Dave's original DCC controller with infrared TV remote back in Sept. .... it worked on Arduino 1.0.6 library release if i remember correctly. I'll bow out and let you guys keep plugging away. Kevin
I think the following code added in bold to serialcommand.cpp and DCCpp_Uno.h should work to control the Pololu board D2 line without the jumper tying D2 to VDD: In SerialCommand.cpp case '1': // <1> /* * enables power from the motor shield to the main operations and programming tracks * * returns: <p1> */ digitalWrite(SIGNAL_ENABLE_PIN_PROG,HIGH); digitalWrite(SIGNAL_ENABLE_PIN_MAIN,HIGH); #if MOTOR_SHIELD_TYPE == 1 //added to control Pololu D2 line digitalWrite(SIGNAL_ENABLE_D2,HIGH); #endif INTERFACE.print("<p1>"); break; /***** TURN OFF POWER FROM MOTOR SHIELD TO TRACKS ****/ case '0': // <0> /* * disables power from the motor shield to the main operations and programming tracks * * returns: <p0> */ digitalWrite(SIGNAL_ENABLE_PIN_PROG,LOW); digitalWrite(SIGNAL_ENABLE_PIN_MAIN,LOW); #if MOTOR_SHIELD_TYPE == 1 //added to control Pololu D2 line digitalWrite(SIGNAL_ENABLE_D2,LOW); #endif INTERFACE.print("<p0>"); break; In DCCpp_Uno.h: #elif MOTOR_SHIELD_TYPE == 1 #define MOTOR_SHIELD_NAME "POLOLU MC33926 MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 9 #define SIGNAL_ENABLE_PIN_PROG 10 #define SIGNAL_ENABLE_PIN_D2 4 //added to control Pololu D2 pin #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define DIRECTION_MOTOR_CHANNEL_PIN_A 7 #define DIRECTION_MOTOR_CHANNEL_PIN_B 8 #else
Actually the two of the lines in message 633 above in the SerialCommand.cpp file need to read: digitalWrite(SIGNAL_ENABLE_PIN_D2,HIGH); digitalWrite(SIGNAL_ENABLE_PIN_D2,LOW); Hopefully my board shows up soon so I can actually test the code before I put it in a message.
No need to bow out... The real goal here, I think, is to build an extensible platform with a variety of features and capabilities that can be tailored to the individual user's needs. Some will want the self-contained WiFi throttle interface. Some will want the basic Arduino + Motor Driver. Some will want JMRI support, some will prefer the Controller interface. Some will want wired simple throttles. As long as we're all pulling together and collaborating, it's all good
And some would like the DCC++ base station to be able to get its commands from a Loconet bus . But I have so much back yard railway civil engineering to do, its an idea that's way before its time. Browsing the DCC++ sketch has revealed a reference to Loconet, so the "concept" might not be totally alien. l can successfully run two G gauge trains with sound and lights using an Arduino Mega 1280 and an Arduino clone motor shield, using a lap top power supply. I have modified the DCC++Controller screen to show only the throttles for two trains and re done the functions to represent my trains. So long as I do not speed and play sounds on both trains at the same time all is well. The currant monitor has been modified to allow 2 amps before shut down. Obviously I will be needing a Pololu motor shield and a bigger power supply eventually but for now proof of concept is perfect, and in all honesty there is only room for one train at a time on what passes for a railway just now. Everybody's contributions are much appreciated. Thank you for sharing your knowledge so that we can get more enjoyment from our hobby. Ross NZ
If life allows I will try to test this tonight. I've been chewing on this issue since Gregg's reply yesterday - the fault signal (SF) on the Pololu is output on Pin 12 by default but that is already used by DCC++ on the Mega so the link is being cut on the Pololu board. If I want to monitor SF it will have to be jumpered to another pin (the Pololu board design makes that easy). But I am also considering the implications of adding an Ethernet card - those all seem to use pins 4 and 10 so yet another conflict. I think that if I want a Mega-Ethernet-Pololu stack then I will have to cut the links for 10 and 4 (and 12) on the Pololu, map SIGNAL_ENABLE_PIN_PROG and the new SIGNAL_ENABLE_PIN_D2 to other available pins and then solder jumpers on the Pololu to tie them in. I don't have an Ethernet card yet to experiment with but have one on the way.
One other thing to try would be to make sure the software short-circuit protection in the code responds faster than the hardware protection in the shield. DCC++ controls this with two parameters found in lines 15 and 16 of CurrentMonitor.h. The parameter CURRENT_SAMPLE_MAX is set to 300. This translates into amps as follows. 300/1024 * 5 V (how the Arduino ADC reads voltages) = 1.465 V at the current pin to trigger a short. For the Arduino Motor Shield, the specs state 1.65V/A, which means the trigger point is at about 900mA. But the Pololu shield is scaled (according to its specs) at only 0.525V/A, which is about 2.8A. This is probably too high to be triggered and the Pololu built-in mechanism is hitting first. Try lowering CURRENT_SAMPLE_MAX to 200 or 150 and see what happens when you trigger a short on the tracks. You can also try to increase the speed of the software response by changing the CURRENT_SAMPLE_SMOOTHING from 0.01 to 0.02 or 0.05. The larger the number, the faster the response, though the higher the probability of a false trigger. -Gregg
Would love to see a video of your G-gauge in action being controlled via DCC++! We could even start an additional user-videos page on the DCC++ web site . -Gregg
TwinDad Is DCC++ Code interface far enough along to allow us to use JMRI DecoderPro to read and write to CV's on the programming track? I just want to change cv 1 from a 1 digit to a 3 or 4 digit road number. it's currently timing out. -------------------------------------------------------- Forget I asked It is an older MRC AD310 decoder just does not want to read/write Olther decoders Working Fine Thanks, Kevin
