I'm trying to install my very first DCC decoder. Before splashing out on a complex/expensive one with sound, I got a low-cost Massoth eMotion XL II PluG Loco Decoder, hoping not to blow up too much in my experiment. At this stage, I've successfully connected: iMac to Arduino Mega2560 via USB Arduino Motor Shield Rev 3 from Arduino to the decoder (hardwired at this stage - not going via any track) Decoder power output to the motor inputs on my engine (see my earlier thread "Help with converting a G-scale Lilliput tram to DCC" in this forum for some background on how I've separated the track power from the motor input.) Through the DCC++ Controller interface on the iMac, linked to the decoder via the Motor Shield's Operations track output, I can successfully throttle the engine forward and back at different speeds - the default decoder id of 3 seems to work fine.) I'm now trying to emulate switching on and off the front and rear lights in the tram, at this stage simply by connecting the appropriate outputs from the decoder to a motherboard with LEDs on it. Initially, I thought I'd just set a CV (in this case 50) to leave the forward light on permanently (a value of 31). I have 2 problems, however: 1. Whenever I power the decoder from the Programming track output from the Motor Shield, the motor starts running at a constant speed. (NB This is true whether I use the DCC++ Controller interface or the simple Arduino Serial Monitor interface.) I wasn't expecting this and assume it isn't correct. Any ideas on what I may have done incorrectly? 2. I can't tell whether any of the CV setting commands I send (either through the Programming or Operations track) are being accepted. Certainly no LEDs are lighting on my breadboard. And also any attempt to read CVs don't return any results. I guess that I may have more success with this if point 1 above can be fixed, but just wondered if again I'm doing anything obviously wrong. Thanks for persevering with a long post. Regards, Les
Hi, Simple question first, when you connect the decoder to the programming track, does the motor run even before you turn on the 'track' power using the <1> command using the serial monitor? You can only read CV values on the programming track, so as you suggest, until you have the motor run problem sorted I'm sure you won't be able to read any CVs. Have you jumpered the motor shield as per Gregg's schematic for using with the Mega here (2nd picture down): https://github.com/DccPlusPlus/Documentation/blob/master/Motor Shield Pin Mappings.pdf Also note that the jumper wire is shown incorrectly in his video of the Mega configuration (if you've seen it), as the software has since changed and now should have pin 2 instead of pin 4 linked to 13 Jim
Thanks for the speedy response, Jim. No, using Serial Monitor, the motor starts on <1> and stops on <0>. Same in DCCpp_Controller using the POWER button. (Actually, I had pin 4 connected to pin13. How can I tell whether I have the latest version of the s/w? I know I downloaded my version back in mid-2017 when I first started playing with the Arduino. I haven't had time to play much since about Sept 2017 so may have missed an update that affects this pin mapping. Connecting pin 2 to pin13 doesn't achieve anything - POWER ON doesn't start the motor; trying to read a CV from the Prog Track in DCCpp Controller gives "Error - Read Failed") Les
The software hasn't been updated as far as I know since January 2016. https://github.com/DccPlusPlus/BaseStation/tree/master/DCCpp_Uno So now you've moved the jumper you don't have the run away motor? When you try to read a CV on the prog track, does the motor give a few 'kicks'? (remember to turn the 'track' power on first!) If it does, I'm thinking that if it isn't on a track, you'll need to load or hold the wheels to create some decent current draw for the current sense circuit to detect. This is how Cvs are read back, by measuring the current pulses that the decoder generates by pulsing the motor. Jim
Thanks again, Jim. I'm getting a bit confused by the results I'm getting now - and also a bit brain-clogged after quite a few hours at this day. I'll try to summarise my findings tomorrow - perhaps after trying to include some track between the motor shield and bogie. Out of interest, where are you based? Nowhere near Cheltenham, are you? Bye for now. Les
Hi Les, I'll await your report tomorrow! I'm in Welwyn Garden City, Hertfordshire. I spent a weekend in and around Cheltenham last September. First day at Prescott watching a hill-climb event, then did a bit of sight seeing. A lovely part of the country. Cheers, Jim
Hi, Jim. Another long post from me, but hopefully logical to read and thorough... Any further suggestions from you gratefully accepted. This morning I modified my setup to include some real track! I now have wires running from the outputs from the Motor Shield to a very short Programming track and to a Main track of a couple of meters. My decoder is connected to power coming through the tram wheels and feeds its output to the tram's motor. i.e. a realistic setup apart from the fact that the tram is currently only comprised of the base bogie - the upper superstructure is temporarily removed. For basic testing, I am using the Serial Monitor interface to the Arduino using the DCCpp_Uno sketch from Gregg Berman, rather than DCC++ Controller at this stage. Summary of results: On the Main track: Throttle works fine. Unclear whether the Writing of CVs is successful, but expected effect (light on) of changing CV 50 doesn't happen. On the Programming track: With Pin 2 connected to Pin 13, both read and Write of CVs return a a result code indicating that the verification read fails. With Pin 4 connected to Pin 13, whenever power is on for the tracks, the tram moves. Also whilst attempts to write to a CV return a result showing a correct verification read, any free-standing CV reads return seemingly random verification values. If it helps, the user manual for the decoder can be found here: https://www.modell-land.de/images/daten/8150101.pdf Paragraph 5.4 (pg 11) talking about Lights, the entry for CV50 on page 23 and its reference to Attachment 1 on Page 29 are what make me think setting CV50 to a value of 31 should switch on the front light. Details of tests: With the tram on the Main track, things seem to mostly work. (I presume at this stage, the jumper wire to Pin 13 is irrelevant? It's actually connected to Pin 2 for this test.) 1. Starting with the Arduino app not running, switched on external power to the Motor Shield. (All 4 lights for the connections to the Main & Ops tracks stay off.) Compile the sketch which make a connection (at 115200 baud) to the Arduino's serial port over a USB connection from my iMac . 2. When "Done Uploading" appears, the 4 lights by the 2 motor connections on the Motor Shield are still off (and the tram hasn't made any attempt to move - power is presumably still off to the tracks). 3. Issue <1> command. Returns <p1> as expected to indicate power now on to both tracks. All 4 lights on the Motor Shield Come on steady. 4. Issue <t 1 3 10 1> command. Returns <T1 10 1> and the tram moves forwards slowly. 5 <t 1 3 0 1> stops the tram; <t 1 3 20 0> moves it slowly backwards. So far, so good. Now try writing a CV 6 <w 3 50 31> returns nothing (as expected). This should have set the CV but on the Main track there's no way of being certain it worked. However, unless I'm misunderstanding the Massoth User Manual regarding which CVs to set and to what values, this should have turned on a light (on a tiny breadboard by the decoder).. (NB I've checked with another trivial sketch that the LED is still functional!) So let's try some things with the tram on the Programming track (with Pin 2 connected to pin 13)... 1. Starting with Arduino app not running, switched on external power to Motor Shield. All 4 lights came on steady. (Is that right?) 2. Opened Arduino app on iMac and complied & loaded DCCpp_Uno sketch. On finishing upload, tram on Prog track briefly tried to move but then the 4 Motor Shield lights went out and the tram stopped. (Should that happen?) 3. Opened the Serial Monitor window on the iMac & entered <1> command. Result <p1>. 4 lights on Motor Shield lit again. 4. Entered <R 50 1 1> command to read CV 50. Returns <r1|1|50 -1> indicating Read Could Not Be Verified 5. Entered <W 50 31 1 1> to write 31 into CV50. Returns <r1|1|50 -1> again. Since I was under the impression Pin 4 should have been connected to Pin 13, let's try some things with the tram on the Programming track (with Pin 4 connected to pin 13)... 1. Starting with Arduino app not running, switched on external power to Motor Shield. Both lights lit on Motor Shield output to Main track; only one light lit on the output to the Programming track; Tram starts running and continues to do so. 2. Opened Arduino app on iMac and complied & loaded DCCpp_Uno sketch. On finishing upload, the 4 Motor Shield lights went out and the tram stopped. Should that happen? 3. Opened the Serial Monitor window on the iMac & entered <1> command. Result <p1>. Three lights on Motor Shield lit again & the tram started running. 4. Entered <R 50 1 1> command to read CV 50. Returns <r1|1|50 255> indicating CV50 currently holds value 255. 5. Entered <R 50 1 1> command again. This time returns <r1|1|50 58>. Third go, returns <r1|1|50 206>... (Seems to think it's getting a valid response but a different value every time.) 6. Entered <W 50 31 1 1> to write 31 into CV50. Returns <r1|1|50 31>, suggesting write was successful. 7. Entered <R 50 1 1> 3 more times. Returns 127, 58 and 239. 8. <0> extinguishes all lights on the motor shield and the tram stops running (at last!) Thanks for reading!
Hi Les, Just skimmed through your post, but I'm a bit confused? You don't need to keep compiling and reloading the S/W into the arduino. Once is enough, preferably with the motor board removed (or at least with the motor power turned off). The arduino stores the program even when power is removed. Then each time you apply power to the arduino and driver board, it should come up with no lights lit on the driver board. With the arduino app running on the iMac you should be able to start the serial monitor and send <1> which should turn all the lights on on the motor bd, and then you can do all the other commands. The fact that you appear to be reloading the code into the arduino each time and with the motor power on and connected, may cause unpredictable results and corruptions. Once you have loaded the software onto the arduino, the only reason you then need to use the Arduino app, is to run its serial monitor. (In fact you don't even need to load the DCC++ code into the app each time - just start the Arduino app empty, then open the serial monitor). You should only ever get all 4 lights lit on the driver board or none at all. If only 3 are lit it means there is a problem. A loco on the program track should never 'run'; my program track (n-gauge) is only 8" long, and I've never had a loco go off the end! When you attempt to read a CV (on the program track) the loco should just give a series of small kicks. I hope this helps, Let us know how you get on. Jim
Another thought Les, How are you powering the arduino? That sounds like possibly there is no power getting to the Arduino until the app is running? I use a PC and that does supply power to the USB connection all the time, I don't know if that is true on the iMac?
Sorry to have confused you, Jim! Firstly, as on your Windows system, the Arduino board does indeed get power through any USB cable connecting it to the iMac, even if no program is loaded or running on the iMac that wants to use the Arduino. When I said "Starting with Arduino app not running, switched on external power to Motor Shield. All 4 lights came on steady", I meant the Arduino was connected to the iMac (& therefore the base board was getting power, but the separate 15V power supply direct into the Motor Shield, needed to send enough power to the tracks was not initially switched on. As soon as I turned on power to that Motor Shield power supply, the 4 lights came on. Regarding the multiple recompiles & reloads, yes, I realise that a sketch, once compiled and uploaded to the Arduino, stays there until another program replaces it. It was just overkill on my part. In the distant past, I did work for a number of years in 1st line operating systems support (having to look immediately into why the mainframe crashed in order to pass the problem to engineers if hardware related; or if software related, to attempt to patch the operating system myself if possible or to pass in on to second line support if it required more time than we could spare. I realise just how difficult it is to be absolutely certain of what has led to a problem on a computer and was just trying to ensure that I was starting from exactly the same state at every major step. Regarding the 3 lights on the Motor Shield, this is only when Pin 13 is connected to Pin 4, which you say is not the way I should wire things anyway. Strangely though, it's this configuration that seems to get valid return values from CV writes on the programming track - but not CV reads. With Pin 13 connected to Pin 2, which is the recommended connection, all 4 LEDs light up on sending a <1> - but neither the CV reads, nor CV writes get any successful return values back. Neither do I get any series of small kicks when trying to read CVs on the Prog track. I really appreciate the effort you're putting into trying to help, Jim - I'm at a loss to know what to try next. But do let me know if you've had enough! Best regards, Les
Hi Les, no, I haven't run out of questions yet! The information I have for using pin 2 is in Gregg's YouTube video - not in the video itself but in the description; He states: So i'm sure you should use pin 2. The youtube video was posted in Nov 2015, so if you are using the software dated since then, you should be ok. If you only get 3 lights when you use pin 4, then I'm sure pin 2 is the one to use. Which motor driver board are you using? It may point to a problem with the current sensing. If the tram doesn't give the 'kick' when you program a CV, then I think it's a red herring when it returns a valid result. I'm afraid I'm going out for the evening shortly, so won't be able to ponder this again until tomorrow at the earliest. Maybe someone else here can confirm that Les should be using pin 2 when using the Mega? I have only used a Uno or Nano so can't be 100% sure.
Thanks, Jim. I'm using an Arduino Motor Shield (Rev 3, as far as I can tell). The DCC Base Station Software is v1.2.1+ It includes lines in DCCpp_Uno.h that (for the Mega2560) declare DCC_SIGNAL_PIN_MAIN 12 and DCC_SIGNAL_PIN_PROG 2 which confirms what you have said all along. Looking at more DCC code (PacketRegister.cpp), I now see what you mean by "should get kicks". I added some extra lines to the code and as far as I can see, I don't get any successful "analogReads" (around line 265 in PacketRegister.cpp). This ties in with the lack of kicks and also your thought that there is a problem with current sensing. I've tried putting some downward pressure (by hand or with a small weight) on the tram bogie, but this has no effect. Do you know of any checks I can do to test whether ANY dcc signals are going over the motor lines to the Programming track, ideally without needing to connect the loco decoder? Or is there a simple change to the DCCpp Base Station code that would swap over the 2 motors - I can't see anything obvious?
Hello again Les, A few more ideas to try; If you have a DVM (test meter) you can check if the program track has a voltage on it when you turn on/off track power (<1> and <0>). Compare that with the main track, It should be similar. The DVM should be set to AC, and I recall you should get a reading of roughly 2/3rds of your track supply voltage, though this does depend on your DVM, because it isn't pure ac on the rails. Also, although a bit brutal, you could check the current overload circuits are working, by briefly shorting (no longer than a couple of seconds) the track out when the power is on. Turn track power on <1>, all 4 leds should switch on, short track out, and in less than 1 second all LEDs should switch off and stay off - even after removing the short, and you should get either <p2> or <p3> reported on the serial monitor depending on whether it was Main or Program track you shorted out. If this works on both tracks then it confirms the current sense circuitry is okay, and that maybe you need to tweak the current sense calibration so the CV read code will work. Jim
Hi, Jim. Hope you had a good evening out! Ignore the comments below if you like. They were written earlier and things are now working! I carefully rewired everything including neatly tinning all the ends of wires and ensuring a really good connection to the tracks. And that seems to have solved it - lights coming on! Is it perhaps that the connections into the Motor Shield were good enough for power to drive the throttle but not clean enough to pick up the current sensing? I'm now getting 16.6V on the tracks compared with 16.3 previously - not a huge difference but possibly enough. Anyway, many many thanks for all your help and perserverence - your support and advice made a huge difference. Is there a way I can send you a personal message with my eMail address, rather than broadcasting it to everyone? If you're ever out this way again, you would be most welcome to call in to discuss trains, play croquet or have the traditional cuppa! All the best, Les (Original response to your last post) I get about 16.3V on both tracks. DVM set to AC as you suggested. Shorting the tracks does give <p2> or <p3> as appropriate. What are the current sense calibration variable that I might need to change and in which direction (and to what values)? (By the way, the post entitled "DCC++ Decoder CVs Reading Problem. Error 308 JMRI" in this board seems similar to my problem - I just hadn't read it before since I don't know what JMRI is about! Anyway, I've just asked on there too what variables to change and also asked whether they think the Motor Shield is too weak for G-scale. Hope you don't mind my sharing the load - and you deserve a bit of free time this weekend!) Les
Hi Les, JMRI is a fully featured software controller package that is supported on several platforms including PC and I believe Apple systems, and is able to connect to DCC++. I don't think you should try JMRI until your basic problem is resolved. I don't use it myself as my layout is quite simple, and I've modified an Arduino based hand held throttle system published elsewhere to suit my layout, so I don't need a PC or similar in order to run my layout. That other thread you mentioned: I believe the problem there was caused because the motor driver board used didn't include any current sensing. Yours obviously does because you have proven that the over current sensing trips, and that it is correctly able to identify which track has the overload. I'm not sure how much current G-scale motors draw, but I presume if it's below around 1.5 amps maximum you should be ok. The variable you could try tweaking to get your CV's to read is "ACK_SAMPLE_THRESHOLD" which is near the top of PacketRegister.h. Apparently some users have had to reduce this from the default of 30 to around 20 or even lower for smaller motors. I guess you could try increasing it in increments of maybe 5 to 50 (just a guess). Or maybe you too need to reduce it for some reason (eg perhaps your motor driver board is less sensitive). You can't do any damage by getting it wrong. Can you confirm whether you've ever seen the tram kick/pulse when you try to program a CV? I know you've noted it doesn't when you read a CV. Just that I vaguely remember someone with those symptoms on this forum By the way, no problem you posting elsewhere! Jim
Hello again Les, Earlier I sent you a personal message, i don't know if you've got it? Hover your mouse over your name at the top of this page, then click on 'Conversations'..... Jim
