Re: Handling of Interval CAN messages

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