Arduino UNO + L298P R3 Motor shield : USB Serial Comms fail

[ProfKlyzlr]

Dear DCC++ team,

First foray into DCC++, and kinda feeling like I'm hitting most of the trees on the way down. The system:

• Arduino UNO
• Deek-Robot L298P R3 motor shield
• JMRI 4.12 and 4.13 tested on both Win10 Home x64 and Raspberry Pi (mSteveTodd RPi image)

The core issue at the moment seems that after only a few minutes, the serial connection from the DCC++ components to the JMRI Host has some form of hiccup, and is unresponsive until JMRI is restarted.

Typical signs that it's broken are:

• Loco on Main track no longer responds to commands from JMRI throttle (continues at last speed/direction value)
• JMRI "Track Power" indicator changes to Yellow ("Unknown") state, and will not return to either RED ("Off") or Green ("On") state.

I have tested :

• multiple USB cables,
• a pair of different Arduino UNOs,
• both PC (Win10 Home) and Raspberry Pi JMRI Hosts
• both having and not-having a loco on the Main Track output

and the symtoms stay constant, only with slightly-varying times between JMRI-launch and comms drop-out.

The "VIn" contact-point has been cut, allowing the Motor Shield to be powered by a 15VDC Regulated 2A switchmode plugpack, while the Arduino UNO is powered via the Host's USB connection. The "Brake" contact-points have not been cut, but there is nothing connected to those pins (Literally just the Arduino UNO and the Motor Shield). The topside Pin 5<>13 and 10<>12 jumpers are in-place.

Thru consultation with mSteveTodd (Mr "EngineDriver" app dev, Many Thanks!), the logs from the various JMRI instances and tests suggest a failure of the Serial Comms, possibly in the "reporting back Arduino > JMRI" half (while it's working, JMRI/ED throttle commands are received, actioned, and the loco moves as-expected with a reasonable reaction-time to changes in throttle setting).

In all instances, the JMRI "DCC++" settings show a baud rate of 115200 in a greyed-out field, so I take it that this is both correct, and cannot be changed from the JMRI Preferences dialog.

Attached are some ZIP files of logs from both the RPi and Win10 test rigs, for reference.

Questions:

• What are the known symtoms of using a "bad" (cheap, clone) L298P R3 motor shield with a UNO in a DCC++ rig? Is unstable/unreliable USB Serial Comm performance one of them? (If Yes, is there a Verified list of absolutely Known-Good working Motor Shield options and sources?)

• Is it possible that a oddball PSU connected to the Motor Shield could cause the Arduino USB Serial Comms to mis-behave? I have tried adding filter caps to the DC-Input of the Motor-Shield in a "blind guess" try to smooth out any switchmode PSU ripple, but no change.

• Could a bad/incorrect USB Arduino UNO driver be to blame? It feels unlikely as I'm seeing the same issue with the same DCC++ hardware connected to both a RPi on Linux and a quadcore laptop running Win10 Home x64, but still possible?

• Any other suggestions, thoughts, or diagnostic tests I should try?

Many Thanks and Happy Modelling, Prof Klyzlr

ProfK_Win10-Home_x64_DCC++_test-logs.zip ProfK_RPi_DCC++_lsusb_and_Full-Debug_logs.zip ProfK_RPi_DCC++_quick-fail_log-files.zip

[atanisoft]

this very likely should be routed to the JMRI team instead of DCC++. It would appear that JMRI is losing its serial connection to the base station but the base station is still behaving normally.

As for your questions, I have not seen any issues with the inexpensive clone boards (Uno, Mega or motor shields). If the Arduino is powered by the USB that shouldn't be a problem for test envs (it is how I power mine as well as the ESP32 boards I test with) but long term setup should be through a dedicated power supply. For the possibility of a driver issue, if you use another program outside of JMRI that can access the serial port (like MTPuTTY or the Arduino IDE) you can confirm that the basic operation of the base station manually outside of JMRI.

[ProfKlyzlr]

Dear DCC++ team,

Just advising that the root of the problem appears to have been found. I must note that it is not "a JMRI issue", but rather a problematic form of Arduino UNO R3.

For reference, and I would Strongly-Suggest that this is added to any "how to build a DCC++ basestation" documentation under "Minimum Compatible Hardware/Components", it appears that Arduino UNO R3s with CH340 or HL340 USB<>RS232 Serial Comms bridge ICs may struggle to properly handle the serial comms a DCC++ system requires.

NB that this is a not a "JMRI on Raspberry Pi 3B/Linux" issue, exactly the same symtoms and consequent JMRI log entries were seen on WinXP, Win7 Home, Win7 Pro, and Raspberry Pi (Steve Todd "access point" image).

In this case, replacing the bad Arduino UNO R3s with UNO R3s equipped with ATmega 16u2 microprocessors, which are performing the "USB<>RS232 Serial Comms" bridge task, immediately cleared the fault symtoms and matching JMRI log entries, and as-we-speak has survived a 48+hour continuous-operation torture-test without issue.

Visually, the Good "16u2-equipped" UNO R3s can be identified by the small square IC near the USB port, and such UNOs also typically have the larger original-format ATmega 328P main processor chip mounted in a socket.

If the main-processor is the smaller "SMD" version of the 328P, has a small rectangular DIL chip near the USB connector, and/or is sold with any reference to "CH340" or "CH340G" in the description, then it is likely a Bad one and should be avoided for DCC++ basestation missions.

FYI, if anyone reports:

• they built a "DCC++ basestation" using a UNO R3
• they connected it to a RPi 3B running Steve Todd's "access point" JMRI image
• but the "Auto Detect" function of the RPi Image seems to stubbornly think that their "DCC++" basestation is a Digitrax PR3

then it is likely that the UNO they are using is one equipped with the problematic CH340 USB<>RS232 serial comms bridge chip.

Ditto for reports of "My DCC++ basestation initially connects and runs with JMRI OK, but after a random period of time the Track Power button gets stuck in "Yellow" (status Unknown) state, and control of any running-trains is lost".

Many Thanks to those who provided valuable assistance in chasing this issue down. Again, please consider adding a basic "Minimum Compatible Hardware" section to the DCC++ Basestation documentation. Such info could-well save considerable wasted time, diagnostic effort, frustration, and $$ for both modellers dipping-their-toe in the DCC++ waters, and DCC++ team-members who handle bug reports here...

Happy Modelling, Prof Klyzlr

[scanlonjrm]

I have checked the arduino uno and it matches the one prof klyzr says should work BUT it doesn't I'm new to using arduino, I have build the DCC++ base station and tested it. I have installed the JMRI software and it connected to a laptop running windows 10. I keep getting these errors from DecoderPro Unable to create connection "DCC++" (D) Serial Port COM# is in use System connection DCC++ provides a null manager for interface jmri.commandstation Unable to run startup actions due to earlier failures I have installed JMRI on 2 different laptops with the exact same error messages I've checked device manager and it looks ok nothing else is using the port. I'm very frustrated having spent several hours trying to resolve this... Any thoughts out there? Thanks Jim