@iorex I’ve had partial success using the Roller485 with the pwrCan module. Your setup looks similar to mine, except I’m using a Core3, so my pin numbers are different. First, check whether your motor is in RS485 mode. The screen on the back should show COM: 485. Second, make sure the motor ID is set to 1. The third line on the motor screen should read ID: 0x01. Lastly, confirm that the motor’s baud rate is 115200 (this is the default). If all of the above is correct, you can move on to the pwrCan module. Did you flip the resistor for RS485 to the ON position? Are the DIP switches configured correctly? I was able to control motor speed over RS485, but I still get the error: “Unexpected response length: 32, expected: 17.” It looks like there’s a communication issue from the motor back to the pwrCan module. As an alternative, you can power the motor using the power pins on the RS485 terminal and send commands via I²C. It requires more wiring, but it works with much less hassle.

@felmue That did it! Thanks a lot!

@dov I think I ran in to the same thing if I understand your question. See if this post helps. It works for my situation https://community.m5stack.com/topic/7458/midi-synth-unit-with-din-trs-connectors-sam2695?_=1760294339690

@felmue Dear Felix, Actually, we have done nearly the same thing. We have connected this module: HopeRF RFM95W to the connectors on the back of the Core2. That works great. We have no idea why the LoRa module does not work with the Core2. Maybe a SPI conflict somewhere deep in the background, maybe a power issue or maybe, and more likely, we are lacking some understanding. Anyway, we have decided to use a Proto board, solder the LoRa module on it and place that on the backside of the Core2. We have to do that for 35 devices, but it is fail save. Thanks for all the effort Regards

@martincollett said in M5Stack 4IN8OUT connectors: M5Stack 4IN8OUT those are not usual ones [image: 1758003924007-2pterm0.png] [image: 1758003924022-2pterm.png]

I have determined that this is a problem in the library. Probably a buffer overrun. It reads exactly 10 bytes at a time, always, and uses a fixed-length buffer (char data;). If more data is pending, it might clobber/lose lines. Almost all I2C read code in the library cannot cope with variable-length GRBL output. I am rewriting those parts of the library.

@kuriko thank you for that useful information

@fabiops21 Hi, I'm having the same problem as you, have you fixed it?

@cepics The RST pin assignment for COMX LTE (SKU:M031-A) is not provided in the materials. However, since the module uses AT commands for control (via UART 115200bps), you may not need a dedicated RST pin connection if using software reset via AT commands (e.g., AT+CFUN=1,1 to reset the module). For Adafruit_FONA compatibility, if a hardware RST is required, you can connect an unused GPIO pin from Core1 (e.g., G2) to the module's RST pin (refer to the module's schematic for exact RST pin location, typically labeled "RST" or "RESET" on the PCB). https://chat.m5stack.com/