Check out the German BMW Ibus here... http://everything2.com/title/BMW+I-Bus

 

it actually says CNTRL < short for Control......

 

Description
The I-Bus was originally intended to handle the needs of the radio, telephone and onboard navigation systems inside the car cabin. It was first available in the 1997 model year, and is now on every car BMW ships, including the popular Mini Cooper. The presence of the I-Bus is what allows BMW to put their navigation computers and, in fact, their stereo systems and amplifiers in the rear of their vehicles, leaving only a slightly-intelligent head unit in the cabin. This head unit does little more than turn control actions (button presses, knob turns, etc.) into I-Bus messages, and display I-Bus-encoded status information (radio channel, CD track names, etc.) on the MID, if available. This is why replacing the stock stereo in modern BMWs can be such a headache.
The I-Bus is based on the K-Bus protocols and hardware. It is, at its most physical, a single wire bus which is run to several points in the car. Various devices can be plugged into this wire, and signals put onto the wire are visible to all other devices plugged into it. Signal contention is the responsibility of each individual device. Bus speed is fairly pokey, at the geek-familiar 9600 bps 8E1 (8 data bits, Even parity, 1 stop bit) - which means the I-Bus is really limited to control data, and cannot be used to stream digital media or for any other such broadband application. The bus itself, as a single wire, is pulled high to +12V - the battery voltage of the car - and pulled low (ground) by the talking device. The wire used for the I-Bus is color-coded white/red/yellow.

NOW I understand what it does....... thats what the TUNER output is, it is just a radio tuner/display controller......

 

Try this link http://web.archive.org/web/20041204074622/www.openbmw.org/bus/

 

Is this a commercial product? How did he program the PIC? It must have been programmed in a specialised adapter before soldering. The SMD work is all reflow oven soldered too indicating a commercial product. For someone who has worked on this for "weeks" I feel you are not being straight with us.

 

Is this a commercial product? How did he program the PIC? It must have been programmed in a specialised adapter before soldering. The SMD work is all reflow oven soldered too indicating a commercial product. For someone who has worked on this for "weeks" I feel you are not being straight with us.

He has been working on it for weeks, meaning, deciphering the photo, and parts, this was something his father designed and had someone else make.

He has lost the original circuit board and wants to build another.....


My .02

 

it actually says CNTRL < short for Control......

Young feller you're a gonna have old worn out eyes someday too!
Hey, I got Tuner right and 1 outa two aint bad!

 

Young feller you're a gonna have old worn out eyes someday too!
Hey, I got Tuner right and 1 outa two aint bad!

I have a feeling it is going to be sooner than later I am almost pushing 40 (1 year and some change to go!)as we speak... and I already have to use a magnifying loop to read #'s on smd resistors....

 

I had just typed a nice long post only be have to log back in and I lost it all.

Here's a little info about it, I need to filter out a message to the tuner, but I also need to let everything pass without problems.

My had had drew up the layout and he send it to his friend/professional for the part to be built, our DIY PCB didn't work out all that good.

Anyways, I know it's not too hard and maybe now, I'll need fewer parts, but for the most parts, I don't think it will be all that bad.
I think he might have sent us a space IC chip, maybe a spare if something we wrong, but I'm unsure, it might be an old chip.

The ibus runs from 10.5-11.5 volts, so it's not the full 12 volts.

Here's a little log from the ibus, most off Radio, nav, tv, phone, radio, CDC and etc runs off he ibus and they all send message to eachother.
Will get another post with more detail really soon.
THANKS FOR YOUR HELP!!!
-----------------------------

Source Device : GPS Module
Destination Device : TEL
Data - - - - - - - - - - - -
A9 0A 30 30
. . 0 0
Full Packet - - - - - - - - -
7F 06 C8 A9 0A 30 30 12
-----------------------------

Source Device : GPS Module
Destination Device : TEL
Data - - - - - - - - - - - -
A9 03 30 30
. . 0 0
Full Packet - - - - - - - - -
7F 06 C8 A9 03 30 30 1B
-----------------------------

Source Device : UNKNOW 6
Destination Device : Nav Locat.
Data - - - - - - - - - - - -
59 21 02
Y ! .
Full Packet - - - - - - - - -
E8 05 D0 59 21 02 47
-----------------------------

Source Device : Board But.
Destination Device : Radio
Data - - - - - - - - - - - -
01
.
Full Packet - - - - - - - - -
F0 03 68 01 9A
-----------------------------

Source Device : Radio
Destination Device : Light Ctrl
Data - - - - - - - - - - - -
02 00
. .
Full Packet - - - - - - - - -
68 04 BF 02 00 D1
-----------------------------

Source Device : GPS Module
Destination Device : TEL
Data - - - - - - - - - - - -
GPS Coordinates
Latitude :50∞ 39' 33.00''
Longitude :03∞ 06' 22.90''
Time :06 33

Full Packet - - - - - - - - -
7F 14 C8 A2 00 00 50 39 33 00 00 03 06 22 90 00 00 00 06 33 55 8C
-----------------------------

Source Device : GPS Module
Destination Device : TEL
Data - - - - - - - - - - - -
A4 00 01 4D 41 52 43 51 20 45 4E 20 42 41 52 4F 45 55 4C 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . M A R C Q E N B A R O E U L . . . . . . . . . . . . . .
Full Packet - - - - - - - - -
7F 23 C8 A4 00 01 4D 41 52 43 51 20 45 4E 20 42 41 52 4F 45 55 4C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 34
-----------------------------

Source Device : Radio
Destination Device : DSP
Data - - - - - - - - - - - -
01
.
Full Packet - - - - - - - - -
68 03 6A 01 00
-----------------------------

Source Device : DSP
Destination Device : Broad. 2
Data - - - - - - - - - - - -
02 00
. .
Full Packet - - - - - - - - -
6A 04 FF 02 00 93
-----------------------------

 

Minutes of the I-Bus

BMW cars in the log is on the individual control units in the networks set up to communicate on the following schedule:

· Source ID
Identification of the subscriber to send a message to another participant wants BUS

· Length
Length of the entire message (not the source ID and length specification itself)

· Objective ID
To identify the subscriber to whom the message is sent

· Data
The message payload

· XOR CRC - checksum
The checksum is used to verify the message. The recipient of the message calculates the checksum and compares them with those contained in the message.





Figure 1.4: Structure of the message log

Each network (K-Bus, I-bus and D bus) transfers data at a baud rate of 9600 bits per second. The communication protocol is 8 data bits, 1 stop bit and even parity (even).

The implementation provides for BMW as the bus master Instumentenkombination. Allowed only if the IKE sends nothing, other bus users to talk '. This facilitates the integration of additional control devices such as MP3 players and can shorten the reaction time, such as steering wheel buttons. ) On the I-bus (as well as the other bus systems with high bus load collisions can occur as a tribute to the flexibility. Therefore, BMW used depending on the equipment several buses.

The following mechanisms are implemented for communication on the I-Bus:
the bus master (IKE) has priority
up to broadcast any message (request) is to confirm (Response) (this is not true for all the messages here I see the bus then an appropriate encoding before)
when the bus is a defined period (eg 20-100ms, to request only after the timeout, for example, 100-1000ms) is not occupied, other participants may send a request
not every bus user is waiting the same time (this is not explicitly regulated, but it flows from the signal duration and timing differences in the control units)
be opened after a certain time, the bus transfer to other control units, '
Collision detection is used, in particular the response should be reviewed.
it is an address used arbitration: The sender address is replaced with the highest bus access when accessing 2 or more participants simultaneously on the bus. It works like this: While the posting address bit by bit is placed on the bus that will test the state of the line. Where a control device such as a 0 (high level) and the line is low, it needs to) give to disturb the bus (without the ongoing transmission of the other ECUs. In the deciding the next bit. Address 00100100 in binary is greater than 00,100,011th
Commands / messages are in the control internally prioritized. According to the priority uses a different interval between the messages ( "Botschaftsabhängige waiting period '): Prio from 1 1.7 ms, 2 from 2.3ms and 3 from 10ms. When a collision is a predefined, conflict Timeout 'used for control in the same domain (same position of the first recessive bits in the address) differently.
no response to a request should come, he will be repeated up to 5 times after every 300ms latency
As the above mechanisms is enough sin only expensive to implement in practice the following procedure to send out messages:

Before a message is sent has to wait for the rest of the bus. This is achieved when there is no Datentransfehr for some time. The time is calculated from the data rate of the bus and the data frame of the serial connection of 10Bit/Zeichen. This data frame is already included in the subsequent accounting (0.104 ms / bit * 10 bit).



There must be at least 1.2 ms of bus inactivity to wait before it can be assumed that no more additional bits transmitted and thus the message of just been an active control device has been completely sent. Then a message can be sent.

This system or this type of collision avoidance is working in practice under the assumption that all control software to keep exactly this very reliable. Actually, this is the waiting time of Busruhe used to before any other control units to send. This also means that important messages can be suppressed under circumstances and to avoid the collisions actually the other ECUs that's why only a maximum of 1 Solte bus user who works under this "quick and dirty" method to connect.

 

With some very simple modules, only a telegram (vehicle is available, 0 km / h) repeated continuously transmitted to the bus. Because on the one hand while the right message is not herausgefilter and besides, the bus is not overloaded meaningless secure release is assured. It can also occur at other vehicle malfunctions. Of these modules is therefore not advisable.

The modules will be better filtered by a microcontroller with I-Bus interface, the speed wire from the data stream. These modules are recommended in any case. Whether it is worthwhile to yourself, given the sharp drop in prices, each must decide for themselves. If the parts and costs are included the purchased is definitely an advantage.
For ambitious hobbyists with knowledge of microcontroller programming, I would still like to give a few tips.

Hardware

- Microcontroller with 2 UART (eg Atmel ATmega162)
- Two I-Bus level converter (see I-Bus Basics)
- Power supply

The module has to be ground between the blue connector from the video module.




Here's most of the address on the ibus system.

ID
(Hex)
Name of Participant Remark
00
General News (1)
18
CD Changer Address of the MP3 player
30
SES (voice)
3B
Video module
3F
DIS external diagnostic system
43
Menu screen on-board monitor
50
Steering wheel buttons Left Side
60
Park System PDC
68
Radio
6A
DSP (Sound Processor)
7F
GPS Module
80
Instrument combination IKE
A8
Unknown
BB
TV module (in the video module)
BF
Light Control Module LCM
C0
MID Multi-Information Display not installed
C8
Phone
D0
Navigation data
E7
Line of text on instrument combination
E8
Unknown
ED
Memory Seats
F0
Key-board monitor
FF
General News (2)