Hi there, I am new to DCC but no novice to programming and electronics. As we are in lockdown, I decided to spend some time expanding my knowledge for enhancing my grandsons modelrailway. my "equipment" so far: Arduino Mega2560 + Arduino motorshield + DCC++CommandstationEX compiled from github source (todays) on Arduino IDE 1.8.13. Roco 41203 ICE (+controller from starter set), info on loco decoder: no visible part#, does not work in 128 step mode on Lokmaus2 Roco NextGen 51401 loco (works with DCC++EX in 128 step mode, only crawls in 14/28 mode, works ok in all modes on Lokmaus2) LaisDcc decoder (working ok in ICE) my problem: I can't get the ICE going with DCC++EX, lights turn on but don't change with direction. additional info: the soundboard and lights decoder in the trailer does work as expected. As first step to debugging I built a simple DCCsniffer (based on Uno) to compare the packets coming from original Roco Lokmaus2 to the ones from DCC++EX, see some samples at the end of the post. Differences I found: messages from Lokmaus2 are allways decoded as five byte, packets from DCC++EX have varying length (3,4 bytse), seem to give the same decoded "command" but esp. "motor controll" are not recognized from the loco decoder. The "weird" packets may be coming from DCCsniffer but only appear on DCC++EX, not Lokmaus2. Feel free to move this post to its own thread if too complex for the sw thread. regads, schufti Lokmaus2: 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 10010000 10010011 A:3 F0 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP 11111111 11111111 00000011 10010000 10010011 A:3 F0 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 01000000 01000011 A:3 R:STOP 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 01000000 01000011 A:3 R:STOP 11111111 11111111 00000011 01110010 01110001 A:3 F:2 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 01110010 01110001 A:3 F:2 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 10010000 10010011 A:3 F0 11111111 11111111 00000011 01111111 01111100 A:3 F:28 11111111 11111111 00000011 10010000 10010011 A:3 F0 11111111 11111111 00000011 01111111 01111100 A:3 F:28 11111111 11111111 00000011 10000001 10000010 A:3 F1 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP 11111111 11111111 00000011 10000000 10000011 A:3 0F off 11111111 11111111 00000011 01100000 01100011 A:3 F:STOP ################################################################ DCC++EX: 00000011 00111111 00111100 A:3 R:STOP 00000011 00111111 00111100 A:3 R:STOP 00000011 00111111 10000011 10111111 A:3 F:2 00000011 10000000 10000011 A:3 0F off 00000011 10010000 10010011 A:3 F0 00000011 00111111 10001011 10110111 A:3 F:10 00000011 10000000 10000011 A:3 0F off 00000011 00111111 10000000 10111100 A:3 F:STOP 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 00111111 10001011 10110111 A:3 F:10 weird packets: 00000011 00111111 10001011 10110111 A:3 F:10 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 00111111 10001011 10110111 AL:9023 F1 F2 F4 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 10000000 10000011 A:3 0F off 00000011 00111111 10001011 10110111 A:3 F:10 00000011 00111111 10000011 10111111 AL:9023 F1 F2 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 00000011 00111111 10000011 10111111 A:3 F:2 00000011 00111111 10000011 10111111 A:3 F:2
ok, after having a go at DCC protocol on bitlevel, I analyzed that DCC sends speed commands (only?) in 128 step format. Is there a command to define suported speed steps per loco? The simple and cheap Lokmaus2 can save the required format per loco address. still mysterious to me: the "long address" packets and the long run of ones following
ok, thanks. That's what I allready expected from a browse through the code. So older equipment that only supports 28 speed steps is deemed "obsolete". Wouldn't it be possible to send speed packets simultaneously in 128 and scaled down 28 version? If the decoder "understands" both versions, that should be the same as the repeated packages? Do you btw have an explanation for the "weird" packages?
It is not possible today with the DCC++ code as written. I'd also not recommend it as it will possibly confuse the decoder to have two packets sent to it with different payloads. You'd need to pick one or the other and DCC++ would need to encode accordingly Sent from my ONEPLUS A5010 using Tapatalk
or maybe have a compiler option (or jumper) to reserve a small addressrange for "old" loco decoders to be served with 28 speed steps (feature request)? Maybe it should be mentioned on the dcc-ex webpage that it only supports 128 ss, not NMRA DCC standard including 128 speed steps, because for NMRA DCC compatible decoders it is only mandatory to support 28 ss, at least that's all I found.
ad "weird packets": they seem to appear during the LCD update ... they definitely disappear when compiled w/o LCD support
there is a "oversight" in the LCD code. It is of no use defining a 4x20 char LCD in the config.h if later on the LCD routines limit the line to 16 char: (LCDDisplay.h) #define MAX_LCD_COLS 16
btw. I made a little "patch" (few lines of code) that reserves a range (0 ... X in config.h) loco adress for backward compatibility with 28 speed step only decoders, no adverse effects observed. No need for API change.
What strange packets are you noticing with LCD enabled with regard to packets? You mentioned an issue when the display updates? Do you get 28 speed steps working? Where is your patch?
some roco trains (~2000) with Roco 10742 V1 (by Lenz) for example. According to dccwiki.com there are even some manufacturers that still only have 28 speed steps - the mandatory version according to NMRA (14 and 128 being optional). So for me it would be priority to at least conform to the standard .... my most rivial patch (DCC.cpp, loco "3" only): void DCC::setThrottle( uint16_t cab, uint8_t tSpeed, bool tDirection) { byte speedCode; // LCD(0, F("cab:%d spd:%d dir:%s"), cab, tSpeed, tDirection ? "F" : "R"); if (cab == 3) if (tSpeed <= 1) speedCode = 0x40 | (tDirection << 5) | tSpeed; else speedCode = 0x40 | (tDirection << 5) | (((tSpeed - 1) & 0x78) >> 3) | (((tSpeed - 1) & 4) << 2); else speedCode = (tSpeed & 0x7F) | (tDirection << 7); setThrottle2(cab, speedCode); // retain speed for loco reminders updateLocoReminder(cab, speedCode ); } void DCC::setThrottle2( uint16_t cab, byte speedCode) { uint8_t b[4]={0}; uint8_t nB = 0; // DIAG(F("\nsetSpeedInternal %d %x"),cab,speedCode); if (cab > 127) b[nB++] = highByte(cab) | 0xC0; // convert train number into a two-byte address b[nB++] = lowByte(cab); if (cab != 3) b[nB++] = SET_SPEEED; b[nB++] = speedCode; // for encoding see setThrottle // LCD(1, F("sched: %x %x %x %x"), b[0], b[1], b[2], b[3]); DCCWaveform::mainTrack.schedulePacket(b, nB, 0); } its trivial to adapt for a range (1...n) defined in config.h The one kind of weird packages is like 00000011 00111111 10001011 10110111 AL:9023 F1 F2 F4 (might be my dcc sniffer, though) occuring right before the other kind, a long run of "idle-packets" that are sent during LCD update.
Trying to install DCC++EX on an Arduino Uno R3 with Arduino motor shield ("Deek-Robot") It was running the Base Station Classic just fine When I launch the Command Station EX Installer, I can select the Base station type, the board type, the motor shield, and the COM port (Arduino Uno on Com 4) But when it compiles and upload, I end up with "Failed to upload because uploading error: exit status 1" What should I do? FYI, there is no power supply attached, only the usb cable from the PC to the Arduino board, and I still have the 2 jumpers on the motor shield Thanks
1st thing I can think of, try the upload with the motorshield removed. other than that you have to wait for the pro's ...
I seem to recall that motor board jumpers are no longer required. Assembly instructions still require cutting the VIN trace: https://dcc-ex.com/get-started/assembly.html Although you used the installer, you can use the Arduino IDE to verify and upload the sketch. Perhaps you'll be able to see a better error message -- whether you're missing a library or need to select a different board or port. The installer will have done much/all these steps: https://dcc-ex.com/get-started/arduino-ide.html -- so figure out where the files are located on your hard drive; you may not need to download anything further.
So I did it thru the IDE and it apparently worked without any error message. I was able to test with the <1> and <0> commands I was looking at the wifi compatible shields/boards in the wifi setup page, but it says to use a Mega: What you will need A Command Station (CS) made from a Mega and an Arduino Motor Shield One of the above WiFi boards Does that mean it will not work with a Uno?
that is correct. For WiFi you need the second serial that is not available on an uno board additionally, the uno is somewhat limited on flash/memory, maybe too much so for additional wifi operations. before s/o asks: softserial seems no option as this (interrupts) might pbly interfere with the DCC generation.
Yes, it should work. The difference is the connection on Pin 2 -- now you use Pin 13. Take a look at this post (and scroll up a few), which might help in explaining the setup vs DCC++. https://www.trainboard.com/highball...x-software-thread.130985/page-11#post-1159212 ===> 5. I previously used pin 2 (and pin 11) for the program track. Now I use pin 13 (and pin 11). Don't hesitate to ask if you need help figuring out how to modify the sketch to accommodate the current sensing using the MAX471. It might be useful to include the Locoduino link. Check motordrivers.h -- read the notes, but put your definitions in config.h When you get it working, post your definitions -- I will refer to them when my MAX471 arrives.
