Re: Handling of Interval CAN messages

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