Votol em100 Canbus Protocols

vogue

1 µW
Joined
Nov 23, 2021
Messages
1
Hey guys,

I have a EM100s Can controller, and im wanting to hook up a telematics device to it via canbus to see all the parameters.
However i am having a hard time trying to "sniff" the data. I can use the canbus programing cable and able to program the controller but when it comes to getting the same information from my canbus sniffer i cant seem to pull any data. Has anyone done this before and have any advice for me. basically i want the same information that the speedo gives but on a mobile platform.
 
Hi Vogue!

Have you made any progress on this? Next month I will start the same attempt...
 
Hey brother.
This is not a standart CAN Protocol Communication.
This is simple RX/TX converted by TJA driver
 
Hey, just wanted to share, so I manage to get the votol data out out the can bus. I used the Votol EM260-SP (SP => can version i think). I dont have an EM100 can version at the moment, but maybe someone might be able to experiment on their EM100 and share their results.

I used the included blue usb2can programmer, and probe its TXD and RXD on its CAN transceiver chip using a logic analyzer. Instead of probing its CANH and CANL, doing this makes sure of the data direction coming in and out of the programmer and votol.

Heres what i found:
First the can bus is 250kbit/s (measured using oscilloscope)
By default, the votol sends some data by itself that contains some information that I havent decoded yet. There are 4 frames with ids 270929954, 269047200, 268981664, 270929955.

To get useful parameters, you need to request it by sending 2 frames, one is
StdId = 1023; Data Len = 8; Data[0] = 9; Data[1] = 85; Data[2] = 170; Data[3] = 170; Data[4] = 0; Data[5] = 170; Data[6] = 0; Data[7] = 0;

And the other one
StdId = 1023; Data Len = 8; Data[0] = 0; Data[1] = 24; Data[2] = 170; Data[3] = 5; Data[4] = 210; Data[5] = 0; Data[6] = 32; Data[7] = 51;

After those 2 frames is sent, votol will immidiately sent 3 frames, all 3 has the id of 1022, and a combined data of 24 bytes. This 24 bytes closely resembles data from the serial communication protocol (theres a thread documenting it titled VOTOL serial communication), with the difference of 2 byte offset.

(copied from the aforementioned thread, with correction to match the can version)
B7~B8:02 14 converts into fixed-point Dec is the battery voltage, for my case it is 53.2V
B9~B10: 00 0f converts into fixed-point Dec is the battery current, for my case is 1.5A
B16~B17: 02 b8 converts into integer is the rpm, for my case is 696
B18: 5d converts into Dec - 50 is the Controller temp, for my case is 43C
B19: 4b converts into Dec - 50 is the External temp, for my case is 25C
B18~B19: 22 d6 converts into integer is the temperature coefficient, for my case is 8918
B22:{
bit0~1= 0:L, 1:M, 2:H, 3:S
bit2=R
bit3=P
bit4=brake
bit5=antitheft
bit6=side stand
bit7=regen
}
votol requested communication.jpg
Note that this information comes from my specific use case with my own setting and might not work on your case (or worse, change parameters or break stuff), so save your working parameters first then start experimenting.
 
This is really cool info, thanks for sharing!!

Were you able to decode the response to the normal 'read' operation for the rest of the parameters?

Code:
[0x55, 0x55, 0xAA, 0xAA, 0x00, 0xAA, 0x00, 0x00,
 0x0A, 0x55, 0xAA, 0xAA, 0x00, 0xAA, 0x00, 0x00]

Is seems this is the read operation, but the output I'm getting seems somehow scrambled and not in accordance with the serial protocol frames. I can decode some of it, but not all.

Is seems that all frames from the controller have the id you mentioned, 1022.

Any clues?
 
Hi @surfacta - any progress here? I have an EM-200-2/SP and it seems to have the same protocol. I managed to get the replies to the "other" type of packets as in my previous post (I'd say this is a config request/update sort of packet), and they seem to conform to the serial format too (still figuring out all the bytes). Were you able to figure out the checksum that seems to be present in the CAN packets?
 
I currently don't have my votol setup anymore, so I couldn't experiment much further. Are you using a logic analyzer like the picture I posted? Before, I used a microcontroller (STM32) to record frames based in its ids, but as I mentioned, votol replied with 3 consecutive frame that have the same ids, so essentially I was only able to see the last frame. Being able to see the communication chronologically makes it way easier to reverse engineer a protocol.

I doubt votol includes any error detection method in its data field, as CAN protocol already provides 15 bit CRC in every packet.
 
Hi @surfacta - any progress here? I have an EM-200-2/SP and it seems to have the same protocol. I managed to get the replies to the "other" type of packets as in my previous post (I'd say this is a config request/update sort of packet), and they seem to conform to the serial format too (still figuring out all the bytes). Were you able to figure out the checksum that seems to be present in the CAN packets?
Untitled.png

quick finding same seting on my execl sheet ... FYI
 
Last edited:
Hey, thanks @fishblood - precisely what I'm seeing! What I'm struggling with is the last part of the message which seems to be a CRC (ED 6D) in your screenshot - which I cannot reverse engineer. I sent you a DM too.
 
Hey, thanks @fishblood - precisely what I'm seeing! What I'm struggling with is the last part of the message which seems to be a CRC (ED 6D) in your screenshot - which I cannot reverse engineer. I sent you a DM too.
In my excel at 07 section, the RED Hex I think its "set compare check value". It's hard to reverse engineering. Luckly, currently use my APK sending setting to controller always work. You can just focus on change your setting to some obvious finding code and read back, then reverse check with the excel for which byte is mapping for CAN bus protocol. I think CAN bus byte setting order is same as normal serial UART on Bluetooth.
 
Greetings I'm working on EM50SP and I'm using the Logic Analyzer to read the RX and the TX pins of the USB2CAN programmer but I'm getting errors in all of my frames I already changed multiple Bit Rates but still get errors on my frames .
Any ideas on how I can fix it?
RX->CH0
TX->CH1
 

Attachments

  • 332331021_199336029441852_6103406273044834983_n.png
    332331021_199336029441852_6103406273044834983_n.png
    38.3 KB · Views: 13
Hello,
I have following raw can data file and the dbc file.. But it's not running.. I am not able to plot my raw can data with the help of my dbc file.. Can anyone help me plzzz??
 
Heres what i found:
First the can bus is 250kbit/s (measured using oscilloscope)
By default, the votol sends some data by itself that contains some information that I havent decoded yet. There are 4 frames with ids 270929954, 269047200, 268981664, 270929955.
I would prefer to use hexadecimal notation - so after powered on my 150/2-SP also writes endlessly repeating the following 4 frames to the CAN-bus:

can0 100955A0 [8] F6 01 FB FF 00 00 42 E6
can0 100855A0 [8] C2 3A 08 64 00 00 09 C0
can0 10261023 [8] 1A BE 00 00 00 00 04 00
can0 10261022 [8] 06 70 00 00 F6 01 FB FF

Some of the bytes may vary if I switch the controller off and on again. The answer of SiaEcosys' support is: "That is our SIA CAN communication protocol, it can not be turned off. If you don't need it, just ignore it."
 
Back
Top