Votol em100 Canbus Protocols

[vogue]

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.

 

[brunopacola]

Hi Vogue!

Have you made any progress on this? Next month I will start the same attempt...

 

[maincraft]

Hey brother.
This is not a standart CAN Protocol Communication.
This is simple RX/TX converted by TJA driver

 

[surfacta]

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
}

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.

 

[ifonul]

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?

[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?

 

[ifonul]

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?

 

[surfacta]

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.

 

[fishblood]

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?

quick finding same seting on my execl sheet ... FYI

 

[ifonul]

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.

 

[fishblood]

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.

 

[BASS19]

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

 

[project@sr]

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??

 

[Rudi Ratlos]

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."

 

[bananu7]

My EM260-GTSP seems to talk in a similar way. The blue dongle sends two frames to 1023, and the controller responds with a standard data frame at 1022.

 

[bananu7]

Just to confirm, I was able to connect and read those frames with a TJA1050 CAN transceiver. Not sure how often the controller can be polled for those frames, and it would actually be quite interesting to decode what's in the ones that it itself keeps sending periodically...

I got around the same frame ID simply by storing three frames in memory and decoding on all three. There's a small risk of catching something incomplete or another frame in the middle, which I observed, but most of the time the three consecutive 1022 frames arrive as expected.

 

[Tylormack]

Hey everyone, sorry for jumping in late on this.

I have a Sondors Metacycle with the EM300S controller installed. It works fine with my stock 72V battery using the CANbus connection, but when I switch to 96V without CANbus, nothing happens.

I initially thought a key switch bypass would solve the issue, but it seems the system requires a CANbus signal to wake up.

Can anyone offer advice or guidance on this? I’ve already programmed the software for 96V, but I’m stuck at the CANbus issue. Siaecosys suggested wiring my ignition to the controller’s positive terminal—would that actually work, or would it still wait for the CANbus signal to activate the 12V step-down?
Any help would be greatly appreciated. Thanks brothers

 

[amberwolf]

You could use some form of MCU like Pico or Nano to "record" the serial data for the wakeup command, then use it to play back that command whenever you turn it on, or push a button , or whatever. Assuming it's just a command and not an interaction over hte bus that generates something diferent each time.

 

[Tylormack]

You could use some form of MCU like Pico or Nano to "record" the serial data for the wakeup command, then use it to play back that command whenever you turn it on, or push a button , or whatever. Assuming it's just a command and not an interaction over hte bus that generates something diferent each time.

To be completely honest here I am so confused at this point haha.

Could I call you or text you for help? I am very new to the ebike world and can do simple votol programming but this canbus issue is beyond my current knowledge. WhatsApp: 1 281 466 7245

If not no biggie I’m sure I can do a deep dive

 

[Tylormack]

Hey everyone,

I’m new to Endless Sphere—glad to be here, but I could really use some help!

I’m trying to power my Sondors Metacycle with an aftermarket battery, but without the proper CANbus signal, the bike won’t turn on. The controller is getting full voltage, and I’ve even bypassed the key switch, but no luck—seems like a communication issue.

If anyone has experience with canbus signal communication , I’d really appreciate the help. Losing sleep over it, lol. Took pictures of all of the plugs below

Thanks in advance, and ride safe!

 

[amberwolf]

I moved your new thread to the same one you've already been posting in to keep your project and info in one place. If you post in mulitple places it's harder for people to help you.

 

[Tylormack]

Thank you amberwolf. My apologies

 

[Tylormack]

You could use some form of MCU like Pico or Nano to "record" the serial data for the wakeup command, then use it to play back that command whenever you turn it on, or push a button , or whatever. Assuming it's just a command and not an interaction over hte bus that generates something diferent each time.

Could you explain further when you have some time? I am still new and lack that knowledge

 

[bananu7]

Basically you create a device that outputs a fixed message on the bus, acting as a dumb "player".
To find out what to send, it would be easiest to record an example handshake between a well-known battery and the controller and just mirror what they do.

Which part of that is confusing?

 

[Tylormack]

Basically you create a device that outputs a fixed message on the bus, acting as a dumb "player".
To find out what to send, it would be easiest to record an example handshake between a well-known battery and the controller and just mirror what they do.

Which part of that is confusing?

to someone that has no software background. pretty frocking hard lol

 

[bananu7]

I mean, you're attempting to reverse-engineer a complex electrical system. If you have confirmed that no simpler methods of activating the controller don't work, it is actually on on the larger battery and waiting to receive the CAN payload to turn on, then I think this is the most straightforward and safe option to follow.

You will need some sort of programmable microcontroller ideally with onboard CAN and a bus transceiver (ideally on a breakout board). I am personally using STM F103 (blue pill board) and TJA1050. It is possible to use a microcontroller without CAN, but then you will need a dual controller-xceiver adapter board that will talk to it via e.g. SPI.

The setup is pretty straightforward. Hook up bus to the adapter, hook up adapter to microcontroller. Software can be written in your embedded framework of choice - I recommend Embassy but Arduino will work fine too. You can look at my Votol repository for example communication with the controller and steal that code if you want.

All of that is relatively straightforward and safe as long as you do preliminary reading and research.

I would make a new thread specifically for your setup if you decide to try this, as it will likely generate a lot of replies during support, which would spam this thread unnecessarily.