Re: Handling of Interval CAN messages

Excellent. Thank you very much Vincent!

On Wed, Jan 21, 2015 at 10:55 AM, Vincent Royer <[email protected]>
wrote:

> 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
> <%28604%29%20576-2971>*
> *mobile: (604) 861-1057 <%28604%29%20861-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
>>
>
>


-- 
Thanks, Josh