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?
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.
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.
Wow, you guys have come a long way since I last posted anything. Anyhow. A friend of mine purchased a Lift e-foil within the last year. After riding he went to charge it. It would not charge. The only indication of life was one little green LED, would flash ON every several seconds. After a few calls and several attempts to revive the battery with tech support, Lift sent him a new battery and said get rid of the old one there is nothing more we can do. So he gave it to me because I had built e-foils. And I don’t think he wanted the hazard around his house. So I got it open. Here are some photos.
I tried to do kind of a master reset by removing the leads at the main relay to drop power to the whole thing. That did not get it working.
My observations. No water inside. all cells measure 3.37. total = 47.24 this was 3 months after the battery stopped working .
Today at least 6 months later all cells measure 3.29. Total 46.10. the green led has stopped flashing.
I’m wondering if its normal for cells to discharge so perfectly over 6 months time. I suspect the BMS is still working???
I currently don’t have a voltage source high enough to attempt to charge the battery. Parts on order.
My plan is to try to use the battery in a new foil build, but first i need to know how to disable all the smart features???
Try first to replace only the master relay, often they Lose contact inside. If you get original charger try it first. maybe all work is done after that. Otherwise use only the cells and put a new bms from daly to it. The Lift bms got its own software that can be crashed totally. If lift support and resetting did fail, rip every cables and electronics of and weld the new bms on to the cells. thats easy and fast to do.
I decided to run the “good bad” and “bad batt” files from an earlier post through chat GPT to help decode and identify the differences between the 2 .txt files provided earlier.
The main purpose of this is to REPLACE the lift BMS with any other BMS and emulate an “ok” signal with an Arduino.
Please comment if this is complete garbage or if it makes sense/is correct. I have no experience with can bus to decode myself.
Here is the conversation and response:
I now have both the “healthy” and “not healthy” battery CAN bus logs. I’ll analyze the differences between the two to identify key signals that indicate a healthy battery. I’ll extract and compare the CAN message IDs, data patterns, and any anomalies. Give me a moment to process the data.
Analysis of CAN Bus Differences Between Healthy and Not Healthy Battery Logs
Missing Messages in Not Healthy Battery
These messages are present in the healthy battery but missing in the not healthy one:
0
28A
328
38A
40A
48A
This suggests that these messages might be important for normal battery operation. If they are required by the eFoil system, their absence could be causing the malfunction.
Extra Messages in Not Healthy Battery
These messages are present in the not healthy battery but missing in the healthy one:
327
The presence of this message in the not healthy battery might indicate an error condition or some kind of failure report.
Key Differences in Data for Common Message IDs
Some messages appear in both logs but have different data payloads. Here are some important ones:
Message 322
Healthy:8 6 0 0 0 DE F E6 F
Not Healthy:8 3 0 C 0 0 0 68 D
Difference: The first byte has changed from 6 to 3, and other values have changed significantly. This could relate to voltage, temperature, or system status.
Message 380
Healthy:8 31 1 30 1 40 1 39 1
Not Healthy:8 16 1 15 1 10 1 E 1
Difference: The values have decreased significantly. This might indicate a low voltage or an error state.
Message 321
Healthy:8 15 E 33 1 A9 3 81 3
Not Healthy:8 0 0 0 0 8B 3 0 0
Difference: The values have been reset to mostly zeros, which could indicate a failure mode or loss of valid sensor data.
Message 312
Healthy:8 FF FF FF FF 0 0 3F 1
Not Healthy:8 FF FF FF FF 0 0 13 1
Difference: The last byte has changed from 3F to 13. This might be a status or error flag.
Message 329
Healthy:8 23 1 28 1 8C 1 C8 1
Not Healthy:8 10 1 10 1 11 1 12 1
Difference: The values have dropped significantly, possibly indicating low voltage or a protection mode.
Message 313
Healthy:8 0 0 1 0 3E 5 8 7
Not Healthy:8 0 0 1 0 30 5 F0 6
Difference: Changes in values, likely affecting power management.
Next Steps
To emulate a healthy battery signal using an Arduino, you should:
Ensure missing messages (0, 28A, 328, etc.) are included in the Arduino-generated CAN bus traffic.
Modify messages like 322, 321, 312, etc., to match the healthy battery data.
Investigate the role of message 327, which only appears in the not healthy battery. It might be an error report.
Test different payload values for 313, 329, 380, etc., and observe the system’s response.
Would you like me to help write an Arduino script to simulate the “healthy” battery signals?
