I have a project which will use 2 Teensy 3.2 and 1 Teensy 3.5 to run a smart dashboard. Presently I have one of the Teensy 3.2 units designated to plug into the Can H and Can L via a can translator. It will do some processing and send some of the data via serial connection to the other Teensy 3.2.
I would like a couple of CAN messages relating to lights on or off (main beam, side lights, fogs) to be passed onto the Teensy 3.5. How best do I do this? Can I plug two units into the CAN translator? Or can I have one unit talking to two using the serial connection?
My suggestion is not to use the existing vehicle CAN bus to send your messages, it can cause all types of undefined problems with the vehicle. Monitoring it is OK but you must not ACK any of the messages on the vehicle bus. Keep your connection invisible as possible. Try this link to get started: CAN Bus Explained - A Simple Intro [2023] – CSS Electronics. Look at the CAN bus as a tuned circuit in the vehicle, and do not detune it. CAN for the OBDII connector is normally not the CAN bus in the vehicle but setup specifically for diagnosis, however this varies by manufacturer. CAN is also bus length limited controlled mainly by baud rate and physical layer. What you want may not be available on that connector. You are going to have to get the proper baud rate, message structure etc before you begin.
Good Luck & Have Fun!
Gil
What sort of body is this project going into? I think you said Mustang before, but I wasn't sure what year.
I ask because, more specific stuff like fog lamps, non-emissions related stuff like that, more likely comes from the body modules. I checked the data I have on the L86 (it's a 6.2 but I think less power than your LT4) and I don't see any headlight/fog lamp related data in the engine controller itself.
For those sensors specifically, I might have to set you up with the proprietary messages to get the data from the Mustang body controller, or you can try to solder onto the lamp switches to read them into a digital input as on/off, with some sort of electrical isolation of course. If you want to go the CAN route with reading from the Mustang controller, you should probably get a second CAN IC for your Teensy, I wouldn't plug the CAN wires of your GM engine into the CAN of your Mustang, assuming it has CAN.
Regarding Gil's point, collisions when trying to talk on the CAN bus are a thing you should watch out for, but if you check the data sheet for the IC you chose, it should have a blurb about it. Usually what happens is you send your first 2 or 3 "ID" bytes to the TX line of the IC, then read back what the result was on the RX line, and if what you read doesn't match what you tried to write, then you've collided with another ECU, you must stop talking and try again once the other ECU's message is completed.
Ok to give some background, the car is a TVR Chimaera, but this is a ground up rebuild, using zero existing wiring from the original car. That is to say that I will be placing this fibreglass tub:
Onto this new chassis, except the engine will be the LT4 crate motor, which comes as a complete new unit from Chevrolet, with a brand new crate motor engine management system. This has its own CAN bus system, but is limited to the vehicle OBD only - there is no body or gearbox CAN system present.
To wire up the rest of the car (HVAC, lights, doors, alarm, windows, mirrors, audio, instruments) I will be using a pair of these. These are solid state power distribution units, and they have 2 CAN systems - one to communicate between themselves, and one to communicate with the rest of the car, and can pull data from the engine OBD to drive any outputs you would like, and it can send out CAN messages onto the CAN network to be shared with any other user.
The only other CAN node I will have will be the Arduino(s) in the custom dash instrument cluster I'm building. This is looking to read CAN data from the engine OBD to display (speed/temps & pressures etc) on either the gauges or a small OLED screen built in. It would also be nice to be able to read potential messages from the power distribution units - e.g. lights on/off, ignition on/off, and things like that. Not essential but it would make the wiring to the Arduinos simpler if I could read this stuff from the CAN network rather than through analogue/digital inputs from the car (which require signal conditioning components which take up space on the board).
Hey sorry for the delay- I had to think about this a bit. Your use case scenario is certainly unique, but I think it should be OK.
If you'd like to read your body module switches from your PMU modules, maybe when you configure them, you could setup an output message that transmits all the switch statuses over a given CAN ID? Then it should be easy for the Arduino to read. It sounds like arduino, PMU and engine will all be on the same CAN network.
The one part you'll have to be cautious on - OBD communication is limited to a single request on the bus at a time. So if your arduino and the PMU are attempting to request OBD data from the engine at the same time, it could be difficult. Something to consider when coding.
I unfortunately dont know what's possible from the PMU at a glance. It sounds like you have lots of flexibility there, so you should he able to schedule periodic transmits from it to the arduino to read switch statuses. You'll have to give the documentation a good read through.
Thanks very much kate, I think I will try to fit in the hardware on the ocb the capability to do both and will then test and see which works best. What sort of rate of messages per second could be run do you think? Are you thinking there could be a noticable delay or is it more a conflict/error problem?
450nick:
Thanks very much kate, I think I will try to fit in the hardware on the ocb the capability to do both and will then test and see which works best. What sort of rate of messages per second could be run do you think? Are you thinking there could be a noticable delay or is it more a conflict/error problem?
Honestly the sky is the limit here. You can work in delays of 10-20 milliseconds as long as you're obeying CAN collision laws, everything should come up basically real time.
