Re: Handling of Interval CAN messages

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