Source code work on few testing arduino nano but failed with timeout error!

[paulsteigel]

Hi, Armin,
Today, I tested on Arduino nano, only one out off 3 work with successful reading of BMS data, the rest return with "Receive timeout at ReplyFrameBufferIndex=0".
I did a test with LGT8F328 (nano style), same timeout error, however, I test the LGT8 board with a different code, just send out BMS request and some data returned successfully (despite of wrong calculation).
===========DATA=========
Data available count:63, Request count:11, Valid count:11
Requesting ...
Valid.
cellCount:13
cell:1 3.77
cell:2 3.77
cell:3 3.77
cell:4 3.77
cell:5 3.92
cell:6 3.92
cell:7 3.77
cell:8 3.77
cell:9 3.77
cell:10 3.92
cell:11 3.77
cell:12 3.77
cell:13 3.77
Capacity:0
Current:-37.67
Voltage:37.67
===========DATA=========
The code for loop as below. I took your requestJK_BMSStatusFrame with Serial listener of SoftwareSerial for send/receiving uart command. First I used your SoftwareSerialTX as provisioned in your code and received nothing at serial.read (I understood that you used SoftwareSerialTX to reduce code). I also use your code with SoftwareSerial (removing some LCD, button..etc for fitting the flash size of the LGT8 board and again. Timeout error raised again. So I doubt, there would be a small bug somewhere at the mechanism of handling the response data from JKBMS and have not yet found the problem.
ReadBMS.txt

=============CODE===============
void loop() {

Serial.println("Requesting ...");

//mySerial.write(dataCmdX, sizeof(dataCmdX));
requestJK_BMSStatusFrame(&mySerial, false); // 1.85 ms

// +1 for the NULL terminator
char str[sizeof(dataCmdX) + 1];
// Copy contents
memcpy(str, dataCmdX, sizeof(dataCmdX));
// Append NULL terminator
str[sizeof(dataCmdX)] = '\0';

printf("%s\n", str);    

delayMicroseconds(2000);
//read data
byteCounter = 0;
int inByte = 0;
while(mySerial.available())
{
  inByte = mySerial.read();
  buffData[byteCounter] = inByte;
  //Serial.print(byteCounter);Serial.print(':');Serial.print(inByte, HEX);Serial.println(' ');
  byteCounter++;
  delayMicroseconds(5);
}
//mySerial.flush();
if(byteCounter > 0)
{
  ProcessDataPacket();
}
reqCount++;
Serial.print("Data available count:");Serial.print(byteCounter);
Serial.print(", Request count:");Serial.print(reqCount);
Serial.print(", Valid count:");Serial.println(validCount);

delay(5000);
}
=============CODE===============
If you have time, please advice! The reason I raised this point is the code work on some nano and some does not (I am testing) evens of the same type.
Please be sorry for being too curious.
Best,
Ngoc

[ArminJo]

Sorry, but your description is too complicated for me.

[paulsteigel]

Hi Armin,
Please be sorry for the complicated explanation. The scenario I have tried was:

• Step1: Use 3 arduino nano board of the same type (LGP8Fxxx) and uploaded with your code: I had "Receive timeout at ReplyFrameBufferIndex=0" error on 2 of them. Only one worked with successful reading of JKBMS data;
• Step2: Take one of the failed one and tested with a new piece of code that using SoftwareSerial (text attached in my previous comment). It did receive some data from JKBMS (despite of wrong calculation - no problem);
• Step3: I used similar approach with your code (change from SoftwareSerialTX to common SoftwareSerial) on the tested nano on step 2 and Serial throw out the "Receive timeout at ReplyFrameBufferIndex=0" again.
  If this explanation is again complicated, please dont be bothered with thanks.
  Best
  Ngoc

[ArminJo]

Now I have got it.
Try to temprarily remove / shorten the schotty diode in the RX line (from BMS). Maybe the LGP8Fxxx boards have differnt logic levels than the standard nanos.

[paulsteigel]

I đi not wire the diode at all Armin

…

On Sun, Nov 12, 2023, 12:24 AM Armin ***@***.***> wrote: Now I have got it. Try to temprarily remove / shorten the schotty diode in the RX line (from BMS). Maybe the LGP8Fxxx boards have differnt logic levels than the standard nanos. — Reply to this email directly, view it on GitHub <#20 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDODLM3ZXBM7IPVA7IPSXDYD6YF3AVCNFSM6AAAAAA7HIKD2KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNBRGUYTC> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>