this post was submitted on 04 Nov 2025
18 points (100.0% liked)

Ask Electronics

3884 readers
63 users here now

For questions about component-level electronic circuits, tools and equipment.

Rules

1: Be nice.

2: Be on-topic (eg: Electronic, not electrical).

3: No commercial stuff, buying, selling or valuations.

4: Be safe.


founded 2 years ago
MODERATORS
 

So I am working on an Arduino project and have trouble communicating over UART.

I have a SIM7600G-H 4G Module from Waveshare and hooked it up to an Arduino Nano ESP32. The connections are as follows:

SIM7600<->Nano ESP32

TXD<->RX0

RXD<->TX0

VIN<->VUSB

GND<->GND

CTS<->D3

RTS<->D12

It mostly works, I can send AT commands and receive responds. However sometimes I only receive parts and chunks are missing or being send to the next command. I strongly suspect RSPs ("unsolicited result code") to be the reason behind it. As documented in the manual RSPs are being send without an implicit action and happens for example if the module receives a call or SMS.

I have read about hardware flow control which seems to theoretically solve the problem of those module talking over each other and have connected the CTS and RTS pins to generic digital pins. According the manual the SIM Module it has hardware flow control enabled as an default.

On the Arduino side of things I have added these lines in hopes of enabling it, however I do not see a change, they do not return any error but I still see data missing. I have also tried swapping CTS and RTS just for fun, but without any luck.

Serial0.setPins(-1,-1,12,3);
Serial0.setHwFlowCtrlMode(UART_HW_FLOWCTRL_CTS_RTS);

Here are the logs which shows some responds being cut off.

20:57:47.991 -> Send AT command: AT
20:57:47.991 -> Response: AT
20:57:47.991 -> OK
20:57:47.991 -> 
20:57:47.992 -> Send AT command: AT+CPIN=1234
20:57:47.992 -> Response: AT+CPIN=1234      <- This responds ending is cut off
20:57:47.992 -> Send AT command: AT+CSQ
20:57:48.025 -> Response:                    <- This responds start is cut off
20:57:48.025 -> OK
20:57:48.025 -> 
20:57:48.025 -> Send AT command: AT+CREG=1
20:57:48.059 -> Response: AT+CREG=1
20:57:48.059 -> OK
20:57:48.059 -> 

And this is my function to send those commands.

char* SIMClass::send(const char* command) {
  // Clear buffer
  while (Serial0.available() > 0) Serial0.read();
  Serial.print("Send AT command: ");
  Serial.println(command);

  unsigned long timeout = millis() + 10000;
  char* response = (char*)malloc(1024 * sizeof(char));
  uint16_t index = 0;

  Serial0.print(command);
  Serial0.print("\r");


  while (Serial0.available() == 0) {
    if (millis() > timeout) {
      response[index] = '\0';
      return response;
    }
  }

  while (Serial0.available() > 0) {
    response[index++] = Serial0.read();
    timeout = millis() + 1000;
  }
  response[index] = '\0';
  Serial.print("Response: ");
  Serial.println(response);
  return response;
}

After enabling hardware flow control unsing Serial0.setHwFlowCtrlMode(UART_HW_FLOWCTRL_CTS_RTS) I expected Serial0.print(message) to wait until the SIM module is not busy and vice versa. Am I wrong in that assumption? Am I missing something else or is it maybe recommend to implement the hardware flow yourself?

you are viewing a single comment's thread
view the rest of the comments
[–] bitfucker@programming.dev 7 points 1 week ago* (last edited 1 week ago) (6 children)

~~I assume you mean RXD to TX0. As for sporadic packets like that, I'd honestly check for the signal integrity. Maybe somehow the data line is picking up noise high enough to cause disturbance. It could be caused by a lot of things, but the most likely culprit are the connector/cable. Any connection going into/out of pcb should be checked. Or check your timing. Make sure the baud and other config (start, data, stop, parity) are matched. Small drift in baudrate is usually tolerable. UART is designed for async communication after all, meaning that any device may send anytime so CTS and RTS isn't usually needed provided that it is a hardware UART (not bit banging). You can check out Ben Eater video about it. In short, the TX is usually held high, the RX then can detect a falling edge which is a signal that a packet is starting. The UART hardware then processes the signal according to the config that you give it and is usually able to do a DMA transfer.~~

Edit: Ahh, after reading the code I suspect that your code processes the data faster than the module can send the full reply. The first loop that you are waiting for the first data to arrive, you immediately process everything in the buffer until it is empty, not knowing that maybe the module has not yet finished transmitting. CTS and RTS would not help since they are used to signal if both devices would like to (or probably could) send / receive data. Not signalling end of data transfer

Edit 2, the solution: Either parse the received packet until the expected end, or wait until timeout before returning.

[–] ChrysanthemumIndica@discuss.tchncs.de 5 points 1 week ago (2 children)

I'd like to concur about reading the receive buffer faster than it is filled!

Hopefully there is some end of line character that can be parsed for, but if not, a timeout should be fine like you said.

Curious what baud rate is being used.

[–] bvoigtlaender@feddit.org 2 points 6 days ago

The Serial on the ESP is set to 115200 as is the default of the module but can be overridden using commands. I should probably double check that. :) However I would assume that having a different baud rate would result in more errors than I am currently experiencing.

[–] bitfucker@programming.dev 5 points 1 week ago (1 children)

Since the posts are about SIM7600, and the example shows, it's probably AT Command. So always newline delimited (either \r or \r\n)

That's fair, and sort of what I assumed, but I don't quite have the experience to say for a fact, so much appreciated!

Ironically I've only done modem stuff when I was very young and also somehow most of last year. But also maybe I get a little paranoid when it comes to talking to devices, and maybe I'm extrapolating my current i2c woes too far 😅

load more comments (3 replies)