Some CAN inspiration needed - de-messing my trike's lighting - Page 1
Forum section: electronics / projects

author: sgofferj
author_rank: Contributor
timestamp: February 20, 2025, 06:08:34 pm
content: So, I have a recumbent tricycle for a few years now. Last year I put a 1kW e-motor kit in it and replaced the battery-operated lights with some 12V lights running through a buck converter from the drive battery. Then I put some turn signals, then I built a box with an ESP32 and a MOSFET driver board and put daylight running lights based on WS2812 and so on, and so on. Of course, the complexity of the wiring increased and now I finally have enough. Inspired by automotive technology, I decided to redo the whole shabang. My idea is to have a CAN bus running from front to back, reducing the wiring to 4 wires and having little boxes with MOSFET drivers closer to the lights. I have read a lot about CAN bus and I think I understand the technical part enough to make it work with ESP32s and CAN transceivers. I just need some inspiration for the protocol design. I tried to find some real life CAN message examples from cars but that stuff seems to be proprietary. Like how does a turn signal work? Does the ECU in the steering column send "turn signal on" and the front light ECU reports back "lamp on" "lamp off" "lamp on" "lamp off"? Or does some central ECU send "Turn left front turn signal lamp on", "turn left front turn signal lamp off, ... Or, speed...? Does the instrument cluster request the speed every x ms or is some ECU just broadcasting the speed all the time? What would good practices be? As I wrote, I'm looking for some inspiration...

author: PGPG
author_rank: Frequent Contributor
timestamp: February 20, 2025, 08:59:17 pm
content: Quote from: sgofferj on February 20, 2025, 06:08:34 pmI have never used CAN but we use RS485 since 90s.My opinion about CAN (may be wrong as I practically know nothing about it) has mainly 2 points:- one state is 'strong' and second 'weak'. Don't know if it is a problem for long cables.- each bit has probably to be 2..3 times longer than propagation time along bus.With RS485 for long lines (like 1km) the next bit can start even the previous one didn't reached the other bus end, I think.We use RS485 without polling. Anyone can send when have something to send provided it check if bus isn't busy. When one starts to send all others know it in few us. The risk of collisions is negligible. Adding some random (counted in us) delays in critical situations and confirming each message solve the problem. Fail safe driver I use is SN65HVD72D.I want only to say. Consider RS485 also.

author: BennoG
author_rank: Frequent Contributor
timestamp: February 20, 2025, 09:03:03 pm
content: I would go for something simpler like RS485.For CAN you preferably need to implement SDO's and maybe also PDO's.We use CAN in our machines but you need special CAN driver and do the collision detection in software of with a sperate CAN controller.for RS485 you can during development even connect the controller directly without RS485 drivers (although it will be more RS422 then)And a scope (digital wit probably a logic analyzer) during development will help a lot.Benno

author: sgofferj
author_rank: Contributor
timestamp: February 21, 2025, 07:14:11 am
content: The ESP32 has an integrated CAN controller which takes care of all of this stuff. Only a transceiver is needed. The hardware and physical layers are fairly painless.Edit:Another advantage of CAN is that the newer ebike controllers almost all use CAN, so if I ever decide to upgrade my drive controller, I could integrate all.Quote from: BennoG on February 20, 2025, 09:03:03 pmSDOs and PDOs would be necessary if I'd use CANOpen over CAN. I don't think, I'm going to go that far.Simple automotive style CAN will suffice.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: February 21, 2025, 09:50:21 am
content: tryhttps://github.com/sugiuraii/ECUSimhttps://dev.to/devjameshay/basic-ecu-simulator-using-an-arduino-1064it will give you a idea how canbus msg's are formated and responded to on ecu's.In old cars they would send messages for other items all along the same bus , eg 1 CAN for all, later vehicle added gateways to split into body, engine, transmission,security etcin my applications i have done request from server ( the canbus light request's status it should be in) and Server transmit status every x period. i found the latter to be easier to implement as all the think is done on the main ecu and all the devices act as slaves.darkspr1te

author: neillnz
author_rank: Contributor
timestamp: February 21, 2025, 10:42:10 am
content: If you use select parts with inbuilt CAN controllers it will be relatively simple to implement as much is done within the controller itself such as collision / contention avoidance, acknowledgement, checksum etc.What I really like about your idea is that it's easily expandable.I work on new cars with CAN, specicially lighting systems. Typically a control module will send messages at a specified rate, typical rates are every 10 ms, 20 ms 50 ms, 100 ms, 500 ms. A message that carries information about which turn signals are to be on might be sent every 100ms. Such a message will typically change by perhaps just 2 bits, one bit to siginify the turn signals is active, the other bit to signify that the lamp/LED is to be off or on. Typically the message that instructs the DRLs to be on will not change while the turn signals are active, in which case the controller within the headlight cluster will see that the turn signal is active and turn off the DRL on that side. You can of course implement the lights with no decision making ability.You might like to start with a system on the bench, all you need are two nodes and one message. Decide on the message arbitration ID, get one node to transmit a message of up to 8 bytes with that arbID and get the other node to look out for a message with that arbID and you have a CAN network! It's that simple.PM me if you want some help.

author: sgofferj
author_rank: Contributor
timestamp: February 23, 2025, 11:17:35 am
content: Quote from: neillnz on February 21, 2025, 10:42:10 amYeah, that was my idea. First step just replicate the current functions, have one central ECU which manages sensors like speed, etc., one for the front, one for the back and one for the controls. Later then maybe a PWS or other fancy stuff.QuoteSo, there's mostly state-independent broadcasting going on?QuoteVery cool to have this insight! Out of interest, how does the control logic for lights usually work? Does the dashboard send a message which is interpreted by the light clusters directly or does the dashboard send the status of the switches and some "central" ECU reacts to that and sends the light commands to the light clusters? I would guess the latter because in modern cars much is configurable, sometimes even user-configurable... And are the light clusters then themselves responsible e.g. for the blinking frequency of the indicators and sync to each other somehow?QuoteAbsolutely! I am already drawing up a "bench-PCB" for holding off-the-shelf devkit modules which can later serve also as my "central ECU".QuoteThat is very generous, thank you!