Hi everyone, I'm new here. I am trying to spoof the wheel speeds on my Chevy through the CAN bus.

I am able to log the CAN packets in the form of 0x00 00 0A RB D0 D1 D2 D3 D4 D5 D6 D7 and send back similar packets.

I have found that if I send packet 0x00 00 01 35 10 xx xx xx xx xx xx xx I can toggle the traction control off and on. Can someone help me find the rest of the ARBIDs? I already looked at "the bible" but I don't think that's what I'm looking for. I specifically want the IDs for the wheel speed sensors so that I can write in my own values if the car isn't moving.

Thank you very much for any assistance or point to the right direction mike

I do not think you'll be able to spoof the wheel speed data.. The wheel speed data is received directly by the EBCM, processed and decisions made by itself with a few other inputs. It's not broadcast across the Gmlan network to another module.. A scan tool can request the data but spoofing that data would accomplish nada.. Also to spoof data anyways you will need to interrupt the data flow that's already there as the correct wheel speed sata would be sent the same time as the spoofed data.. You'd need to either figure out how to stop the original correct data from being sent in order to spoof it.

I've been inspired to order an arduino, can-bus shield and raspberri pi. My aim first off is to create an mp3 player that integrates with the stock headunit and steering wheel controls. I'm not sure if I'll get there, but I'll try and post up what I manage to achieve! The next aim will be to create a full blown car pc.

Any tips/tricks/sample ardunio code etc would be greatly appreciated.

From what I have learnt reading through the forum thread the steering wheel CAN codes seem quite well understood but I can't find any codes for buttons on the stock head unit (next/previous track, the turning knobs, etc). Do button presses on the headunit broadcast over the CAN?

The VE Series I Sat Nav unit does broadcast a bit of information over the SWCan via the NIM Gateway module.

(The NIM Gateway module basically connects to the Blaupunkt BUS, and interfaces with this BUS using the SWCan Bus.

Typically this is used for,1) Sending some of the headunit button and knob data to the Navigation Unit when in Navigation mode.2) Sending Text and icon data to the Instrument Cluster (For Street Names, directions and distance info)3) Sending the current GPS time from the Nav unit to the Headunit for time synchronization.

--On a side note, I recently tried the Carberry shield for the raspberry Pi.On paper this shield looked very promising (2 SWCan Bus lines, and 2 OBD Lines), plus lots and lots of other Lines for various things, however I have to say the shield has been a bit of a disappointment.

The SWCan Lines are not programmable (They will interpret a tiny subset of the SWCan 29 Bit data, mainly steering wheel control data), and the firmware for the drivers on these things is closed source - non expandable.

Also documentation on this thing is severely lacking, to the point where I would honestly say it is around 20% complete.The manufacturers of the thing have promised updates and improvements in the documentation, but I have noticed nothing new since late July 2014.

ZerOne wrote:On paper this shield looked very promising (2 SWCan Bus lines, and 2 OBD Lines), plus lots and lots of other Lines for various things, however I have to say the shield has been a bit of a disappointment.

The SWCan Lines are not programmable (They will interpret a tiny subset of the SWCan 29 Bit data, mainly steering wheel control data), and the firmware for the drivers on these things is closed source - non expandable.

Also documentation on this thing is severely lacking, to the point where I would honestly say it is around 20% complete.The manufacturers of the thing have promised updates and improvements in the documentation, but I have noticed nothing new since late July 2014.

No kidding, does look good on paper, bit big if your only after logging/sending some can data. But for processing video.. or even navigation to the headunit, it would do that great!Pitty to hear its a disappointment!. I thought you'd stick to a modified version of the arduino CAN shield since at least you can tinker with some well tested and commented source code?

Which was shortly lived after I touched pins while moving the board when powered up.. releasing the magical smoke that makes everything work

I did get a little bit of odd responses... could have been my slice and dice approach on some CAN libraries.. wont know till I get the tech2 or something similar to output some gmlan frames that Im certain off and debug the whole process.

Also found the arduino memory size... is a tad small. Id have to upgrade to a bigger mcu to add more functions... hmmm