Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

can bus, just a question

Status
Not open for further replies.

DrDoggy2

Member
I know some of yall started tapping in to can buses, just wondering how that went, specifically I was wondering if you were able to write instructions successfully, and if there was any conflict where the main ECU would overwrite an instruction sent, ie ...I envision that if I plugged in to the can and say sent an instruction to turn on the headlights the main ECU would say nono lights are to be off.. causing an end result would be a momentary flash of the lights?

or where you tell the ECU the light switch dial is on, but on next poll the dial says the truth that its off, another situation causing a momentary flash of the lights. I guess I'm just wondering about the feasability of parallel controls through the CAN and where/when conflicts would take place.

I have seen that onstar hackers can turn on your wipers remotely, i assume that the onstar wifi connects to the CAN and sends instruction to ECU, but also how to find that instruction without hammering or reverse engineering, since i assume its different instruction than either the switch gives or headlight receives? I guess I wonder if I can create myown onstar wifi for my car that doesnt have it using a CAN interface and ESP. and wondering how much control i can take!>?
 
It depends on the form of the signals on the CANbus.

In some cases the signal has a form like:-
0 = The headlights are off
1 = The headlights are on

If the CANbus you access is of this form, you will generally get a fight and short flashes of light if you try to inject a signal.

In other cases the signal has a form like:-
0 = do nothing
1 = turn headlights on
2 = turn headlights off

If that is the case you can probably inject a signal of the right form to get the headlights to do what you want. You will only need to inject a signal when the the state changes.
 
so the slave device only reports on change? i thought the master sends a request to get that report?
CANbus doesn't have "Masters" and "Slaves". Any module on a CANbus will initiate its messages. Other buses, like LIN, I2C, and SPI have a "Master" module that initiates every message.

In cars, most messages on CAN are sent periodically, whether or not any other module is receiving that message. For instance, on one car I looked at, the four wheel speeds were sent as four 16-bit values in one message, sent every 20 ms.

Other messages are sent when something happens, like a button is pressed or similar.

Occasionally, a CAN message will be sent in response to another CAN message. That happens a lot during diagnostics, where a tester will request information from a module, but it sometimes also happens outside of diagnostics. Diagnostic requests never happen on a car in normal running, unless some aftermarket product is used. The diagnostic messages on CAN change less from vehicle to vehicle, and from model year to model year, than the normal CAN messages, so it's easier for aftermarket products to use the diagnostic messages than the normal ones.

Obviously, the contents of a CAN message can change in response to another CAN message. Taking the example of the headlights, you could have both types of message on one CANbus.

Here is a possible scenario:-
The module that controls the headlights transmits continually whether the headlights were on or not. The instrument cluster uses that information to illuminate or not the headlight icon. When the ignition is first turned on, this signal says the headlights are off, so the headlight icon is off.

In this scenario the headlight switch is one of those that always returns to the same position, and it almost always either transmits nothing, or it transmits a signal that means "do nothing".

When the driver operates the switch to turn on the headlights, the switch transmits a signal to say "turn on the headlights". That is only sent once.

The headlight module receives that, turns on the headlights, and changes the signal to say the headlights are on. The instrument cluster receives that and illuminates the headlight icon.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top