Re: Handling of Interval CAN messages

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