Re: Handling of Interval CAN messages

Sure, start with the service manual for the car.  Get the diagrams for the
suspension and ECU, put them in a dropbox or something and share them, I'd
be happy to take a look.

*--*


*Vincent RoyerElectrical Project CoordinatorIntercontinental Truck Body
<http://itb.ca/default.aspx>*

*email: [email protected] <[email protected]>phone: (604) 576-2971*
*mobile: (604) 861-1057*

On Wed, Jan 21, 2015 at 8:31 AM, Joshua B <[email protected]> wrote:

> Thanks Vincent. I'll look into the BCM side of things as I'm pretty
> certain from further testing that I can't accomplish this over CAN. Anyone
> have any good sources on where to start with monitoring the ECU?
>
> On Wed, Jan 21, 2015 at 10:24 AM, Vincent Royer <[email protected]>
> wrote:
>
>> I wouldn't give up so easily.
>>
>> On many vehicles the switches are controlled by the BCM (Body Control
>> Module), over an isolated bus specific for the human interfaces. The BCM
>> will have another bus that connects to the ECM, which may be what is
>> controlling the actual suspension components. If that's the case, you won't
>> be able to interact at the CAN level with this information while connected
>> to the BCM side CAN. Perhaps the switches are hard wired into inputs or
>> multiplexed in some other way to the BCM. I would try to snoop on the ECU
>> side can bus and see if you can find the message there.
>>
>> Alternatively, you can disconnect the suspension from the ECM (or
>> whatever control module is driving them) and provide your own controller.
>> I imagine the dampening adjustment is just a PWM or stepper type valve that
>> rotates different sized orifices in the damper body to speed up / slow down
>> the transfer of fluid in the shock. It should be pretty simple to map out
>> what the settings do to those solenoids using a multimeter.  Then, get a
>> used "suspension controller" or whatever it is, gut the internals, and
>> provide your own controller inside the case.  That way it will be
>> plug-and-play with the oem equipment. Make sure your new controller has a
>> CAN interface and you would be able to essentially reprogram what each of
>> the settings of the buttons do, to your heart's content.
>>
>>
>> On Wed, Jan 21, 2015 at 6:50 AM, Joshua B <[email protected]> wrote:
>>
>>> That's a sinking blow... I had big ideas for this in my race car. Anyone
>>> have any knowledge of where I should look next for a function that isn't
>>> available over CAN?
>>>
>>> On Tue, Jan 20, 2015 at 9:11 PM, Vincent Royer <[email protected]>
>>> wrote:
>>>
>>>> That's my bet.
>>>>
>>>> I have done the exact same thing with a highway truck, trying to
>>>> control a function using the J1939 message instead of the switch itself. I
>>>> went through the same procedure, and found very similar behavior. It did
>>>> turn out to be the LED on the switch, and had nothing to do with the
>>>> function itself. As it turns out, the switch function in my case was not
>>>> available over CAN.
>>>>
>>>> *--*
>>>>
>>>>
>>>> *Vincent RoyerElectrical Project CoordinatorIntercontinental Truck Body
>>>> <http://itb.ca/default.aspx>*
>>>>
>>>> *email: [email protected] <[email protected]>phone: (604)
>>>> 576-2971 <%28604%29%20576-2971>*
>>>> *mobile: (604) 861-1057 <%28604%29%20861-1057>*
>>>>
>>>> On Tue, Jan 20, 2015 at 11:42 AM, Joshua B <[email protected]> wrote:
>>>>
>>>>> Rufus,
>>>>>
>>>>> Thank you for the reply. I believe I caught everything you were saying
>>>>> and you also gave me a possible reason to my results. It's possible I've
>>>>> just discovered the messages controlling/monitoring that light on the dash
>>>>> instead of the backend function. The button changes the mode for the cars
>>>>> suspension and I guess it didn't occur to me that the messages I found
>>>>> could just be turning the light on/off and not actually performing the
>>>>> backend function.
>>>>>
>>>>> On Tue, Jan 20, 2015 at 1:06 PM, Rufus V. Smith <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>  Hi Josh,
>>>>>>
>>>>>>     Most CAN messaging (in my somewhat limited experience) is really
>>>>>> "state" information, rather than "event" information.   You are looking to
>>>>>> cause a "light on" event.  Unfortunately the way the light works is by
>>>>>> receiving the light switch state, and using that to turn off/on the light
>>>>>> output.  If there is any notion of "event", it is done by the device
>>>>>> receiving the switch state, and noticing it has changed from the prior
>>>>>> "state".
>>>>>>
>>>>>>   The button appears to be alternate action, rather than momentary.
>>>>>> That is, push it once, it goes on and stays on, push it again and it goes
>>>>>> off and says off.    If it was momentary, it would only be on WHILE IT WAS
>>>>>> BEING PUSHED, and off upon release. The light controller would keep it's
>>>>>> own memory of the light state, and your method may have worked.
>>>>>>
>>>>>> Rufus
>>>>>>
>>>>>>
>>>>>> On 1/20/2015 12:26 PM, Joshua B wrote:
>>>>>>
>>>>>> Hello Everyone,
>>>>>>
>>>>>>  I'm new to the list and also new to CAN. My interest in CAN started
>>>>>> when I decided I wanted to know what all was happening with the network in
>>>>>> my modern car. This led to me finally picking up a Kvaser interface and
>>>>>> monitoring the CAN bus. My first goal was to try track the CAN ID & message
>>>>>> that is sent when a specific interior button is pressed. Once I found the
>>>>>> message, I then wanted to attempt sending the message myself to see if I
>>>>>> could get the same result without physically pressing the button.
>>>>>>
>>>>>>  The first phase of this was a success, but it wasn't as simple as I
>>>>>> expected... It turns out that when the button if depressed (off) the
>>>>>> network is transmitting a specific message in 2ms intervals. The message is
>>>>>> the same except the last byte loops from 0 to 255 over and over.
>>>>>>
>>>>>>  When the button is pressed (on) the message flips the values of 2
>>>>>> bytes and then continues the loop of the last byte from 0 to 255 in the
>>>>>> same interval...
>>>>>>
>>>>>>  Button OFF = 0         211         7   0   6 192  15   0   0 0-255
>>>>>> <--Byte Loops
>>>>>>
>>>>>> Button ON   = 0         211         7   8  14 192  15   0   0 0-255
>>>>>> <---Byte Loops
>>>>>>
>>>>>>  My initial thought was that I could just send the "ON" message and
>>>>>> hopefully the already steady interval messages would somehow follow suit.
>>>>>> That sadly wasn't the case. When I sent my message, the dash light
>>>>>> indicator for the button simply blinked instead of staying on because the
>>>>>> car was still sending the loop of "OFF" messages. I could script flooding
>>>>>> the "ON" messages, but this wouldn't be the proper fix and I assume the
>>>>>> function of the button wouldn't be stable.
>>>>>>
>>>>>>  So my question is what is the best way to go about dealing with
>>>>>> interval packets like this? Is there a way I can get the network to drop
>>>>>> the packets?
>>>>>>
>>>>>>  --
>>>>>> Thanks, Josh
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rufus V. Smith
>>>>>> FW Telematics
>>>>>> 303 Norwich-New London Tpke.
>>>>>> Uncasville, CT 06382
>>>>>> [email protected]
>>>>>> (860) 848-6600 x 115
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks, Josh
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks, Josh
>>>
>>
>>
>
>
> --
> Thanks, Josh
>