[timn]

Guys,

I've been tinkering with the OEM alarm. Trying to decode the signals going to the siren. Here's what I've learned already.

There are two goals to this:
1. Sense when the siren is being sounded off
2. Create my own sound effects (more on this later)

refer to the attached image

So, what I have done so far is I have hooked up a logic probe to the BLACK x's and then to the data bus. I lock the doors, and i see a pulse.

Then, I hooked up the data bus line to the micro controller and attempted to sense a pulse. It worked, i was able to sense a pulse (a few 1044 micro second pulse)

Anyway, then I tried to send that signal back via a micro controller. This is where it gets weird.
1. When the logic probe is connected to the BLUE x's and then the data bus, i sense the pulse going out.
2. When the logic probe is connected to the BLACK x's and then the data bus, I don't sense the pulse emitted from the micro controller.

I was thinking that I may have to hook up the micro controller to the same power source to sense the signal w/ the probe and ensure its a clean pulse. And lastly, hook up an o-scope to get an accurate idea of what's going on and reproduce the pulses i'm seeing with the logic probe.

I want to add a proximity sensor to the OEM alarm. However, our alarms are not capable of a "warning chirp", it's either armed or not. Being able to produce my own sounds would allow me to produce a "warning chirp". This can also be used for the shock sensor.

Anyway, I'll repost once I get further along, but if anyone has any experience reverse engineering signals, then please, chime in!

[tintivilus]

here's a couple thoughts off the top of my head...

1) are your signal ground referenced to the car somewhere? If the uC circuit doesn't have the same reference ground, then your (single-ended) data signal is hosed....

2) I've not worked with vehicle busses before, but I'd guess they're pulled down (or up) awfully hard to counter-act noise. Maybe your uC isn't sourcing (or sinking) enough current to move the bus, and you need a high-current driver of some kind in between.

[timn]

Originally Posted by tintivilus

here's a couple thoughts off the top of my head...

1) are your signal ground referenced to the car somewhere? If the uC circuit doesn't have the same reference ground, then your (single-ended) data signal is hosed....

2) I've not worked with vehicle busses before, but I'd guess they're pulled down (or up) awfully hard to counter-act noise. Maybe your uC isn't sourcing (or sinking) enough current to move the bus, and you need a high-current driver of some kind in between.

Thanks for the tips. My uC can can only Source 20mA and Sink 25mA per output. I'm not sure what the stock system's source/sink is, but I'm sure its more than that.

I purchased a high current driver (I work at in a hardware division of my company, so I can order sample parts easily). http://www.superdroidrobots.com/shop...y.asp?catid=49 Hopefully this will work. If it doesn't, i'll find use for it somewhere else.

Hopefully, I can setup the o-scope and analyze the data bus tomorrow.

[tintivilus]

Those look like they're intended for motor control.... you might not be able to get the kind of speed you need for communication.

Is the siren just a CAN-bus node? As long as you're taking pot-shots at hardware, maybe try a CAN driver?

google suggests... http://www.kvaser.com/can/products/drivers.htm

for example:

AMIS-30663: CAN High Speed Transceiver with true 3.3V and 5.0V logic level interface
This transceiver is the interface between a controller area network (CAN) protocol controller and the physical bus and may be used in both 12V and 24V systems.

[Ryan 330i]

wow, i am interested in the outcome.

[timn]

Originally Posted by tintivilus

Those look like they're intended for motor control.... you might not be able to get the kind of speed you need for communication.

Is the siren just a CAN-bus node? As long as you're taking pot-shots at hardware, maybe try a CAN driver?

google suggests... http://www.kvaser.com/can/products/drivers.htm

for example:

I'll look into the CAN-bus stuff this weekend.

Took a shot at hooking the data bus line to the oscilloscope. Here's a shot of what happens when you lock the car. One audible tone, and one distinct signal. My next thought is to see if this is a CAN-bus compatible data packet.

The shot's not very high res, but thats ok since it doesn't capture the entire data packet in the main window. But you get the idea...Data bus line is high (5v or so) and pulled low.

[tintivilus]

that's pretty neat. I'm *really* curious if that data packet corresponds to a "chirp now" command, or something like a "the car is locked" announcement. Have you checked to see if there's any non-alarm-related traffic on the wire? It might be useful in a structural sense to find out if that wire is a general information bus or specifically communication between the alarm and the siren.

[avincar]

You're probably seeing a status message, and various modules generate their responses. "Lock command" will probably cause the doors to lock, the lights to blink (if they do that), and the siren to chirp. Individual commands will not be on the bus.

[timn]

Originally Posted by tintivilus

that's pretty neat. I'm *really* curious if that data packet corresponds to a "chirp now" command, or something like a "the car is locked" announcement. Have you checked to see if there's any non-alarm-related traffic on the wire? It might be useful in a structural sense to find out if that wire is a general information bus or specifically communication between the alarm and the siren.

When I bought the alarm, it came with the installation instructions and a wiring diagram. AFAIK, the wire between the ultrasonic module and the siren is a direct connection, no other wires tap into it. I'll try to scan it later, but you can also see this from the shock sensor DIY


It's pin #7

There doesn't seem to be any non-alarm traffic. I didn't have my oscilloscope hooked up while the car was running, so i can't say for sure. Right now, when the car is off, it only sends signals when chirping.

[timn]

Originally Posted by timn

It's funny what you see at 1AM...

I just realized something, tintivilus, that wiring diagram of the ultra sonic module has K-CAN low and K-CAN high signals, as well as a data bus line. So, that does confirm that this system is a CAN-bus system (the transceiver link you sent me earlier, and my investigation of CAN-bus operation also corresponds to these lines).

Now i'm really psyched about learning about the CAN-bus system.

[timn]

Originally Posted by avincar

You're probably seeing a status message, and various modules generate their responses. "Lock command" will probably cause the doors to lock, the lights to blink (if they do that), and the siren to chirp. Individual commands will not be on the bus.

Hey Avincar,

I checked out your website. Nice that you guys install security and sound. Have you had any luck adding functionality to any BMW OEM alarms from years 2000+? I think they're all made similar (i know the e46 model is very similar to the e90/92 alarms).

[tintivilus]

After browsing through that DIY (completely forgot about that!) it looks like the alarm system has a CAN interface to the rest of the car (via the ultrasonic module) and just one "local data" wire between the two modules. I don't think there's such an animal as one-wire CAN; maybe the siren is driven via a simpler standard?

this might provide some things to look for

http://www.interfacebus.com/Design_C...utomotive.html

[tintivilus]

While you're investigating that one-wire bus, here are a few suggestions for noodling out the message protocol:

capture several instances of each command, and several different commands.

If a single command has a portion that varies between captures it could be a time-stamp or sequence number. This field can then be isolated from the rest of the message, and usually the part before it can as well (assuming its part of a header like [source device][destination device][seqnum][length][body...])

Now compare the invariant parts of each command to see what varies between those. This will help show the actual command data vs the invariant header (eg source/destination address)

Try re-injecting a command on the bus, and see if you can get the siren to respond. (h/w wise you might just use a high-sink-current inverter or buffer on the uC output) and watch with the oscope to see if you get the appropriate timing and voltage swings. If you do, and you get no response, then part of the message might be a sequence number or timestamp. From here on out it's basically a big exercise in pattern recognition; hopefully by this point you can correlate the structure to a published standard.

If your car hates you, each command will be unique (ie re-sending a captured command will not yield the action again). This usually implies a structure that includes both a timestamp/seqnum and a checksum or parity bit. Hopefully this is simple enough to glean from the various copies of each command you captured above.

The output driver looks like it can be pretty simple, but make sure you get something with a response time substantially higher than the symbol rates you're seeing on the bus in case you need to futz with timing. Since you just have power/data/ground I'd guess timing is pretty lenient, but it'd suck to keep failing just because your output isn't fast/square enough.

[Autobot]

You soo need to get it so have the wolf whistle or have it play Dixie, that would be sweet...

[Autobot]

Sorry I know a bit uncalled for but I couldn't help myself

[skimo]

Do not mean to HI-jack the thread. But a buddy of mine was able to get a hold of a CAN bus protocol analyzer. I am an EE but new to cars. Can someone point me to where I can get access to a CAN bus on the e90? I want to probe the bus and see what messages I can extract...I prefer an easy access location without having to cut wires.

Thanks
Skimo

[timn]

Follow the diagram in post #10

[skimo]

Thanks! I was able to probe the data signals (K-can bus) and got readings on the messages going back and forth.

Captured messages that seems to be initiated when you "unlock" "lock" on the remote. Problem is there are thousands of messages that go across the bus as soon as you do an "unlock" on the remote. Still havnt figured out which ones mean what. We are getting there though...

[HighVoltage]

Originally Posted by skimo

Thanks! I was able to probe the data signals (K-can bus) and got readings on the messages going back and forth.

Captured messages that seems to be initiated when you "unlock" "lock" on the remote. Problem is there are thousands of messages that go across the bus as soon as you do an "unlock" on the remote. Still havnt figured out which ones mean what. We are getting there though...

Just dug up this thread. I was just searching about KCAN bus locations for someone else. Any progress? If you are still interested in this project let me know, I have alot of CANbus tools and I have been working with various CANbus protocols (DeviceNet, SDS, J1939, etc) for over 8 years.