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?
So one of the tricks I learned from reverse engineering the 3 layer PCB of the Nintendo Game & Watch anniversary Mario handheld, is that the engineer(s) that designed the board routed ground traces between every single line. Every button, and every signal had a ground trace around it with very few exceptions. I was given some low quality xrays of the board after I had already retraced the entire thing using continuity and vias. I then pieced together the internal routing using the xrays.
My point is that all signals on a board include a magnetic component. Electrons actually flow backwards from ground because all electrons have a negative charge. We think of conventional current flow from positive to negative, but that is technically incorrect. There is a magnetic field that is created by that flow, and the size of issues this field creates are primary determined by any additional distance traveled between the signal and ground.
Additionally, you may have brown out conditions periodically impacting one peripheral. Something like a UART module seems like a small thing, but back in the 1980s, that was an entire chip on a board of a microprocessor. It has a ring buffer and several registers. It may be causing issues when these are loaded up with high values. Try increasing the capacitance on your power rails to see if that solves the problem.
I do not know the output configuration. If it is an open collector, where pull up resistors are used, you need to select the best resistor value to get sharp edges. You may need to check that the logic low value is within the required range of values. You could put a Schmitt triggered buffer in between the devices to see if sharp edges improve performance like with a 74(x)2G17 for a modern 2 gate surface mounted option or with a more old school 74(x)241. The (x) is the series, which you select for architecture and speed. For almost everything, you will be using CMOS 74 series, and in most instances, 74HC will be fast enough. Generally speaking, 74LS is only compatible with old bjt stuff, 74HCT is for converting between LS and HC type stuff, and most LS and HC stuff will not work together. The static HC stuff is MUCH lower power and what most chips use. You just need to be sure to match the power to your devices. This page will help you find logic stuff for this type of issue: https://en.wikipedia.org/wiki/List_of_7400-series_integrated_circuits. It is totally overkill, but tossing in a buffer with sharp Schmitt triggered edges is a quick hack to see if your issue is potentially related to RLC or grounding.
For the FX2 chip. They come in 2 varieties. Don't get the one in the little enclosure with just 8 lines. There is another cheap board that is bare and has all of the chip pins broken out and labeled in the solder mask. This one works with up to 16 channels. It can be super handy to see all the extra signal lines or create extra trigger signals.
The actual developer of Pulse View has a tutorial here: https://www.youtube.com/watch?v=dobU-b0_L1I