The problem is the USB implementation used on Microchip CPUs. I believe the CPU used in the Digitrax family is a PIC24 series microprocessor from Microchip. I have had problems with the USB CDC implementation as used in the Microchip libraries. I'm not sure if the Microchip code is the problem, or if there is an underlying problem in the design of the CDC (Communications port) USB specification.
As I said above I have had problems with both Linux and Windows communicating with Microchip based devices using the Microchip libraries for their USB processors, with random lockups after a period of time. I have access to some MERG USB-CAN interfaces, some of which use a PIC microprocessor that has built in USB interface, and these periodically lock up even though there is no active message passing, but other devices that use an FTDI chip to do the USB interface to a serial port on the Microchip processor will run for ages without a spot of bother.
The quick solution is to use a Locobuffer type device rather than the USB port.
On Mon, 31 Mar 2025 at 18:23, Cliff Anderson via <cliffaa=[email protected]> wrote:
Dale,
?
When our club replaced the DCS200 several years ago with a DCS210 (not the 210+ or the 240+) there was a lot of chatter on the /g/Digitrax-Users group messages about the built in USB locking up.??
?
That same issue cropped up and stopped our layout several times within the first hour of operation.
?
We surmised that the command station internal CPU and/or internal memory were not sized correctly for simultaneous bursts of message traffic, at least for controlling a large layout with PanelPro.??
?
The same LocoBuffer-USB we had been using on the DCS200 continues to served us well.?
?
As a strange aside, the DCS210 we us at our workbench for DecoderPro and usually with only one locomotive at a time, works well with the internal USB.??
?
Maybe Digitrax still uses the same or similar hardware on the DCS240+ but that is for others to comment on.
