Packets out of sequence about diybmsv4 HOT 17 CLOSED

@delboy711 Can you share your esp32 port, I'm looking at doing the same for the controller side.

A note about HardwareSerial.flush() on the esp32, it will flush both RX and TX. TX waits for the hardware TX queue to empty and RX is flushed by reading bytes until no data is available. Looking at the usage of FlushSerial0() I'd recommend using your current delay option OR use Serial.flush(true) which is available via arduino-esp32 master code (it is not in 1.0.4 which PlatformIO picked up). You can pick up the master code via the following update in the platformio.ini file:

[env]
platform_packages =
  framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git

Place this at the top of the file and it will override the arduino-esp32 code that is being picked up with the latest master code from GitHub.

from diybmsv4.

@atanisoft You can find my ESP32 port at https://github.com/delboy711/diyBMSv4
I am using ESP32 because I need three serial ports. The third serial port will be managing my charger charge rate.

The hardware.Serial.Flush is on the ATTiny841, not the ESP32. If I put a loop cable on the ESP32 controller it see its own packets in the correct sequence so they are not being held up in the ESP32 input buffer.

Just to be sure I tried out your suggestion and used the ESP32 github master, although there are no instances of Serial.Flush in the controller code. No difference.
I also tried the latest github for the ATTiny core
platform = https://github.com/platformio/platform-atmelavr.git
No difference

from diybmsv4.

You can find my ESP32 port at https://github.com/delboy711/diyBMSv4
I am using ESP32 because I need three serial ports. The third serial port will be managing my charger charge rate.

Thanks for the info on your port, I'm looking at a similar setup where I will monitor the batteries and an EPSolar charge controller via RS-485 so I have a single portal for everything.

The hardware.Serial.Flush is on the ATTiny841, not the ESP32. If I put a loop cable on the ESP32 controller it see its own packets in the correct sequence so they are not being held up in the ESP32 input buffer.

Ahh yes, the ATTiny side has the flush, it is possible the two MCUs are out of sync due to the differences in MCU speed. You might try dropping the ESP32 side from the default (240Mhz) to 80Mhz (minimum to support WiFi).

I also tried the latest github for the ATTiny core
platform = https://github.com/platformio/platform-atmelavr.git
No difference

This will only update to the latest PlatformIO code for AVR and not the ATTiny core used by the ATTiny841, you can try:

framework-arduino-avr-attiny @ https://github.com/SpenceKonde/ATTinyCore.git

which should pull the latest code.

from diybmsv4.

Is the esp32 big or little endian?

from diybmsv4.

Is the esp32 big or little endian?

little endian per the tech sheets.

from diybmsv4.

Can you get a copy of the debug logs from the serial port on the ESP32 (Serial1).

The ESP code should wait for a reply for the previous command before issuing another command.

from diybmsv4.

@stuartpittaway Here is the log with the delay(8)

Connecting to WIFI
MQTT Enabled
Connecting to Wi-Fi...
Connected to Wi-Fi.
. Connected IP:192.168.1.99
Requesting NTP from time.google.com
Connecting to MQTT...
Connected to MQTT.
Got NTP time: 19:50:22 15/12/2019
S:80/1/1=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =925/Q:2 # R:81/81/1=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =DDDA
S:80/3/2=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =7301/Q:1 # R:81/83/2=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =C928
Rules:000000111=N/F
S:80/4/3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =CA8E/Q:0 # R:81/84/3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =7F7F
S:80/1/4=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =C5D6/Q:1 # R:81/81/4=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =1129
S:80/3/5=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =9799/Q:0 # R:81/83/5=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =2DB0
Rules:000000111=N/F
S:80/1/6=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =EDBD/Q:1 # R:81/81/6=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =3942
S:80/3/7=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =BFF2/Q:0 # R:81/83/7=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =5DB
Rules:000000111=N/F
S:80/1/8=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =34AC/Q:1 # R:81/81/8=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =E053
S:80/3/9=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =66E3/Q:0 # R:81/83/9=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =DCCA

and here it is with hardware.FlushSerial0() (I added some debug text)

`Connecting to WIFI
MQTT Enabled
Connecting to Wi-Fi...
Connected to Wi-Fi.
. Connected IP:192.168.1.99
Requesting NTP from time.google.com
Connecting to MQTT...
Connected to MQTT.
Got NTP time: 20:02:42 15/12/2019
S:80/1/1=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =925/Q:2 # Rules:000000111=N/F
S:80/3/2=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =7301/Q:3 # R:81/81/1=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =DDDA Out of sequence ** FAILED PROCESS REPLY **

Rules:010000111=N/F
S:80/4/3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =CA8E/Q:2 # R:81/83/2=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =C928 Out of sequence ** FAILED PROCESS REPLY **

S:80/1/4=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =C5D6/Q:1 # R:81/84/3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =7F7F Out of sequence ** FAILED PROCESS REPLY **

S:80/3/5=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =9799/Q:0 # R:81/81/4=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =1129 Out of sequence ** FAILED PROCESS REPLY **

S:80/1/6=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =EDBD/Q:1 # R:81/83/5=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =2DB0 Out of sequence ** FAILED PROCESS REPLY **

S:80/3/7=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =BFF2/Q:0 # R:81/81/6=D0D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =3942 Out of sequence ** FAILED PROCESS REPLY **

Rules:010000111=N/F
S:80/1/8=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =34AC/Q:1 # R:81/83/7=3F00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =5DB Out of sequence ** FAILED PROCESS REPLY **
`
There is a pause after the first packet is sent while it waits for a response. All subsequent packets receive a packet in response immediately. Just the wrong packet :-(

@atanisoft framework-arduino-avr-attiny did not help. Worth a try though.

from diybmsv4.

How strange!

Do you have a wemos D1 you can try the original code on?

I think it's likely to be the code on the attiny which disables the serial port to save power.

But very difficult to debug

from diybmsv4.

Actually just a thought, there is code in the esp which sends a zero byte to wake the modules. Is that still in your code?

from diybmsv4.

@stuartpittaway

Do you have a wemos D1 you can try the original code on?
Not easily. They are all in use. I will have to rummage around and find one.

Actually just a thought, there is code in the esp which sends a zero byte to wake the modules. Is that still in your code?

Yes. Porting to ESP32 required very few changes to your code. Mostly just finding the correct libraries to use. The cell module wakes successfully and the light flashes to signal the packet is received. It appears to be switching off the serial port before the packet is serialised out.
One interesting thing I noticed is if I make the delay less than 8ms. Instead of the packet being truncated as I expected due to the hardware shutting down mid way through the packet, it goes back to sending a complete packet out of sequence.

from diybmsv4.

Are you using the platform io for the attiny does it program the fuses correctly?

from diybmsv4.

If you leave the serial.flush in the ATTINY code but remove the line "hardware.DisableSerial0TX();" does the serial work okay?

I'm expecting this will work but will use more power as the transmit pin are never switched off.

from diybmsv4.

@stuartpittaway

Are you using the platform io for the attiny does it program the fuses correctly?

Yes. The fuses burn OK. The fuse settings I am using are
board_fuses.lfuse = 0b11100010
board_fuses.hfuse = 0b11010110
board_fuses.efuse = 0b11111110

There is some ambiguity In your platformio.ini file about lfuse . There is the comment line
; lfuse = 1110 0010 = CKDIV8 & Calibrated Internal 8MHz Oscillator
It says CKDIV8 is selected, but bit 7 is shown as '1' which is unselected. I have tried it both ways, it does not make any difference.

If you leave the serial.flush in the ATTINY code but remove the line "hardware.DisableSerial0TX();" does the serial work okay?
I'm expecting this will work but will use more power as the transmit pin are never switched off.

Yes. Remove the hardware.DisableSerial0TX() and it all works perfectly.

Getting my calculator out. If the packet is 38 bytes long, then at 4800bps a packet will take 7.92ms to serialise so an 8ms delay before switching off the transmitter is about perfect.

from diybmsv4.

As expected, it looks like the transmit buffer is being ignored and the hardware shuts down before completion - effectively the Flush is not doing anything useful.

I would increase the 8ms delay if this is how you are fixing the problem as the packet length can vary based on its contents (due to the packet handling library).

Just a thought - perhaps the core ATTINY code has recently changed - can you try burning the pre-compiled version from github releases and see if that one works?

from diybmsv4.

@stuartpittaway

Just a thought - perhaps the core ATTINY code has recently changed - can you try burning the pre-compiled version from github releases and see if that one works?

That does not work either! So the problem is to do with the ESP32. The packets must be being held up in the input buffer.
Thinking about it. When the ATTiny shuts down its transmitter, that will put a constant '0' on the line which will look to the ESP32 like a 'break' signal. ESP32 supports UART break signal interrupts, so if a break is detected before the receive buffer is emptied, then it may disrupt the read in some way. I shall see if it is possible to mask UART break signal interrupts in ESP32 and see if that helps.

In the mean time I have a workaround. Thanks so much for the help in at least partially understanding what is going on.

from diybmsv4.

Did you get a resolution to the ESP32 problem?

from diybmsv4.

No. It was too much like hard work investigating further when the 10ms delay in the cell modules works effectively. Closing this issue now.

from diybmsv4.