Cutting open commercial batteries! (Lift, Onean, Flite, etc.)

EFOIL.builders Electronics (ESC, remote, batteries)
306

CANOpen has the concept of NMT node control and NMT node monitoring frames, both of which are present in the CAN logs provided earlier in this thread.

NMT node monitoring indicate that two different nodes are sending their “heartbeat” using identifiers: 0x700 + NodeID

  • node 1 (0x701)
  • node A (0x70A)

Both CAN logs start with node A sending the 7F = pre-operational state. In the “good batt” logs we can later see node A transitioning to the 05 = operational state. node 1 is only seen sending 05 = operational state in the logs.

In the provided logs these CAN frames appear as:

70A 1 7F
701 1 5
70A 1 5
  • The first value represents the CAN frame standard (11-bit) identifier (as hexadecimal)
  • The second value represents the CAN frame DLC (how many data bytes are in the frame)
  • The remaining values are the data bytes (0-8 bytes, each as a hexadecimal value)

The NMT node control frame (0x000), seen in the logs as 0 2 1 A, only appears in the “good batt” log with two bytes of data:

  • 1 = command: start device
  • A = node A

So potentially node 1 is the eBox and node A is the BMS?

307

CANOpen also has the concept of Emergency frames (EMCY) utilizing the identifier: 0x080 + NodeID.
They are only to be transmitted once per error event with frame data as per:

  • 1 byte: Error register
  • 2 bytes: Emergency error code
  • Up-to 5 bytes: Manufacturer-specific error information

The logs contain such EMCY frames with id 0x08A from node A, presumably the BMS, but they appear in both “Good batt” and “Bad batt” logs so they are probably not the main cause for one battery to be considered as working and the other one not.

08A 8 [00] [00 00] [00 00 00 00 00]
08A 8 [30] [81 01] [20 80 00 00 00]
08A 8 [30] [81 01] [1E 80 00 00 00]

The emergency error code is in the manufacturer specific range? (if so, probably makes it hard to decipher more)

I’m guessing that the remaining frames in the logs are PDO:s according to a predefined mapping scheme, potentially without any convention between CAN frame identifier and the sending node id. The interesting battery data is likely hiding within these frames.

If we could get CAN logs from only the battery or the eBox on the CAN bus we could maybe figure out more details.