Switched to firmware version 1b393e4_2020-11-02 comms errors

Daemon_D · 2020-11-05T17:50:36.201Z

I switched to firmware version 1b393e4_2020-11-02
I downloaded the new firmware version only in 2 modules and already got strange behavior.
Packets stop arriving periodically. Reboot helps for 4-15 packets. What could be wrong?

stuart · 2020-11-05T21:32:58.487Z

Did you update the controller code as well? (And upload file system image)

Daemon_D · 2020-11-05T21:36:04.837Z

Yes. Where did I get the firmware version from then?
I completely cleared my memory that I had to re-configure the wifi

41101×208 14 KB

Now the situation is like this

stuart · 2020-11-05T21:50:12.557Z

Did you have the CRC errors before the update? This should always be zero.

Daemon_D · 2020-11-06T06:34:31.524Z

stuart:

Did you have the CRC errors before the update? This should always be zero.

Not so many. Because of what they are?

stuart · 2020-11-06T07:36:00.839Z

CRC errors are indicative of communications errors - normally due to bad connections and/or electrical interference.

So you have two options if you are still seeing problems;

Continue and flash all the modules and see if that resolves the problem
Go back a version on GITHUB and reflash that version - although the latest version doesn’t alter the way the communications code works, so I don’t know what that appeared to introduce comms issues

Daemon_D · 2020-11-06T07:43:44.572Z

It can be a problem (RX) of wire twisted pair 90cm long?

stuart · 2020-11-06T08:02:37.856Z

If you are already using twisted pair cables then that should be okay 90cm is long though, do you have a photo of the install? The modules should be as close to the battery cells as possible (short power leads).

Daemon_D · 2020-11-06T15:16:17.286Z

IMG_20201106_1805354608×3456 1.53 MB

IMG_20201106_1805444608×3456 1.94 MB

IMG_20201106_1805593456×4608 1.36 MB

Perhaps the problem is not in receiving packets, but in their transmission? Whether it is true that the inscription tx means that the controller has sent a packet, but whether it has received it or not, it does not know. Can USBASP be turned on in monitoring mode on module 0 and understand if a packet is coming? Or does a green LED indicate that the module has received a packet? Maybe he got the package already broken? Why should there be short power wires for battery models?

stuart · 2020-11-07T14:34:15.104Z

Daemon_D:

Why should there be short power wires for battery models?

Importance of short power cables to the modules diyBMS

I recommend putting the balancing modules as near to the cells as possible, connect directly to the cells if possible. This makes it easy to isolate and identify which module belongs to what cell etc. shorter cable paths also reduce resistance.

Daemon_D · 2020-11-07T19:55:01.078Z

5812×198 12.5 KB

Solved!

61295×1309 453 KB

The problem was the power supply. These contacts are probably not designed for high currents. Connected temporary power supply via USB. Why not provide a separate on-board power input for power supply, so as not to occupy the USB

stuart · 2020-11-09T07:56:25.340Z

Daemon_D:

Why not provide a separate on-board power input for power supply, so as not to occupy the USB

Yes, I’ll include this on the next controller board version.

stuart · 2020-11-09T07:57:27.089Z

Daemon_D:

Or does a green LED indicate that the module has received a packet?

When the green LED flashes, it means a packet was received, correctly processed and sent on.