Why do I have these CAN mappings on 0x3F
Posted: Mon Mar 02, 2026 2:41 pm
TLDR: I'm quite new to this whole thing and I noticed my CAN mappings on ID 63 (0x3F) are not the same as in the wiki. What went wrong?
I recently started working on a projekt involving the openinverter board for the Tesla LDU and full CAN controll. naturally I looked up the CAN mapplings and found that ID 0x3F has a fixed mapping with all relevant controll signals as lined out in the wiki. But sending the commands cause the inverter to drop CAN communication.
Thanks to the openinverter-can-tool I was able to save the current active mappings and open them in Savvy-CAN. This is where I first found the descrepancy. The ESP-32 web GUI does not show any can mappings.
I would expect the mappings to match the mappings from the wiki but I got the following:
pot, pot2 and canio are the same as expected. Byte 4 bit 0 to 5 are the CAN speed (0x00=125k, 0x01=250k, 0x02=500k, 0x03=800k, 0x04=1M). The cruisespeed parameter is not available for me.
Both canrun fields are still checked and cancrc is also checked but I have not yet been able to correctly generate the crc-code.
Sending 0x02 as byte 4 has resolved the connection issues as the CAN-speed now stays at 500k. I have also been able to send pot values that are received by the inverter.
The first thing after finding a descrepancy between the CAN-Mappings was for me to update the inverter once again with a redownloaded 5.40-sine firmware but it did not change anything.
Digging a bit into the code I found that the mapping is hard coded to the CAN-ID as outlined on the wiki. This makes it even more confusing than it already is for a new setup.
One minor bug I found along the way: Version 5.40 reports as version 5.39 in the web GUI as it is defined in the code.
Now to my question: What have I done to break my CAN mappings in this way?
I will collect possible solutions and answer questions I'm able to until the 5th March when I will be at the shop with the Motor and inverter again.
I recently started working on a projekt involving the openinverter board for the Tesla LDU and full CAN controll. naturally I looked up the CAN mapplings and found that ID 0x3F has a fixed mapping with all relevant controll signals as lined out in the wiki. But sending the commands cause the inverter to drop CAN communication.
Thanks to the openinverter-can-tool I was able to save the current active mappings and open them in Savvy-CAN. This is where I first found the descrepancy. The ESP-32 web GUI does not show any can mappings.
I would expect the mappings to match the mappings from the wiki but I got the following:
pot, pot2 and canio are the same as expected. Byte 4 bit 0 to 5 are the CAN speed (0x00=125k, 0x01=250k, 0x02=500k, 0x03=800k, 0x04=1M). The cruisespeed parameter is not available for me.
Both canrun fields are still checked and cancrc is also checked but I have not yet been able to correctly generate the crc-code.
Sending 0x02 as byte 4 has resolved the connection issues as the CAN-speed now stays at 500k. I have also been able to send pot values that are received by the inverter.
The first thing after finding a descrepancy between the CAN-Mappings was for me to update the inverter once again with a redownloaded 5.40-sine firmware but it did not change anything.
Digging a bit into the code I found that the mapping is hard coded to the CAN-ID as outlined on the wiki. This makes it even more confusing than it already is for a new setup.
One minor bug I found along the way: Version 5.40 reports as version 5.39 in the web GUI as it is defined in the code.
Now to my question: What have I done to break my CAN mappings in this way?
I will collect possible solutions and answer questions I'm able to until the 5th March when I will be at the shop with the Motor and inverter again.