iBUS installation location

[PropellerHead]

Originally Posted by Crowz

There is no advantage to putting the adapter in the back of the car. Using my howto you can see where to tap into for the ibus adapter. Any device in the car that is on the ibus will have the same "signal" quality no matter where it is. Its a bus not an antenna wire.

I'm not terribly sure ab this. For about 3 weeks, I have been fighting an SLS error that has effectively disabled my iBus connection. The app will not see data on the bus. Oh, but it sees *some* data! It gets mileage, coolant temp, and a couple other things but not sh!t from the LCM/MID. I changed absolutely NOTHING and the app suddenly threw errors after the SLS troubles began.

Well, this isn't exactly true. The app *will* show lights and turn signal data from the LCM on the image. So the LCM communicates. But something will not allow messages to pass through to the MID. I cannot program my MID functions. My time and date will not update. I cannot program the light functions, comfort blink, or any of that. I cannot set DRL options and control them in the app, but I can with an AutoLogic which throws no LCM errors. I do get MPG data however. Random, rt?

I've even fiddled with the silly USB connection again to satisfy the folks with the app. The error I am getting is 'No communication from control unit'. Even though the app offers the error, the folks who offer the app have essentially shrugged their shoulders.

Of course, getting ANYONE to look into this silly USB and Android radio app is an exercise in futility. - even an Indy who's become a friend over the past 20 years.

• I have ordered a couple of new USB units from Rolf- they should be here this week while I am gone.
• Can't count the number of application settings and other twists and turns I've had.
• I have replaced one air ride part and have ordered new front/rear height sensors and a rebuilt 4 corner pump.
• I will have an idea of what's going on this week or next- Probably next.

As referenced above, it's real easy to look at this as an air suspension problem, and that is *part* of the problem. The *real* issue I am having is why the communication with the bus from the app and interface is suddenly sh!t- in the face of this SLS error.

I've done some reading about how messages travel along the bus. Different priority messages get different priority along the bus. Also as above, it seems like the application may not be sending at the same priority as the EHC and other sensors.

So, as part of what I am going to ask that they try, I *will* find this wire from the LCM and tap directly in. This will prevent the lengthy, noisy voyage from the LCM, back to the back of the car, then up to the radio- 5 feet from where it started. It *should* avoid a *ton* of noise as it shortens the 'commute' along the bus by a ton.

But it's all theoretical for now. I just know that I am having a weird error that the app folks cant figure out and the Indy will not ever need to find the answer again. So it's up to threads like this to whack-a-mole the problem till it goes away.

[Crowz]

Originally Posted by PropellerHead

I'm not terribly sure ab this. For about 3 weeks, I have been fighting an SLS error that has effectively disabled my iBus connection. The app will not see data on the bus. Oh, but it sees *some* data! It gets mileage, coolant temp, and a couple other things but not sh!t from the LCM/MID. I changed absolutely NOTHING and the app suddenly threw errors after the SLS troubles began.

Well, this isn't exactly true. The app *will* show lights and turn signal data from the LCM on the image. So the LCM communicates. But something will not allow messages to pass through to the MID. I cannot program my MID functions. My time and date will not update. I cannot program the light functions, comfort blink, or any of that. I cannot set DRL options and control them in the app, but I can with an AutoLogic which throws no LCM errors. I do get MPG data however. Random, rt?

I've even fiddled with the silly USB connection again to satisfy the folks with the app. The error I am getting is 'No communication from control unit'. Even though the app offers the error, the folks who offer the app have essentially shrugged their shoulders.

Of course, getting ANYONE to look into this silly USB and Android radio app is an exercise in futility. - even an Indy who's become a friend over the past 20 years.

• <LI abp="813"><LI abp="943">I have ordered a couple of new USB units from Rolf- they should be here this week while I am gone. <LI abp="944">Can't count the number of application settings and other twists and turns I've had. <LI abp="945">I have replaced one air ride part and have ordered new front/rear height sensors and a rebuilt 4 corner pump.
• I will have an idea of what's going on this week or next- Probably next.

As referenced above, it's real easy to look at this as an air suspension problem, and that is *part* of the problem. The *real* issue I am having is why the communication with the bus from the app and interface is suddenly sh!t- in the face of this SLS error.

I've done some reading about how messages travel along the bus. Different priority messages get different priority along the bus. Also as above, it seems like the application may not be sending at the same priority as the EHC and other sensors.

So, as part of what I am going to ask that they try, I *will* find this wire from the LCM and tap directly in. This will prevent the lengthy, noisy voyage from the LCM, back to the back of the car, then up to the radio- 5 feet from where it started. It *should* avoid a *ton* of noise as it shortens the 'commute' along the bus by a ton.

But it's all theoretical for now. I just know that I am having a weird error that the app folks cant figure out and the Indy will not ever need to find the answer again. So it's up to threads like this to whack-a-mole the problem till it goes away.

If something causes chatter on a bus system where your connected doesn't really matter. The chatter is a packet issue. Basically on a bus system there are protocols that handle the packets transmitted. This system allows for many devices to be connected to the same data path aka the bus. Its a great method for packing devices onto a connection that doesn't require but one wired path aka its cheap

The drawback with this method is everything MUST be compliant. Any one device that misbehaves can take out the entire bus rendering all devices dead. Random misbehaving will result in certain data loss but might not be enough to take out the entire system. This will result in some data being passed successfully and some being lost. It can be random or in your case just certain things not working.

The normal method to test this is to remove the offending device from the bus. If you unplug it and things work flawless you found your culprit.

Location on the bus doesn't really matter "signal wise" but you can effect what is seen on the bus and what data gets to the bus controller.

So if a device at the middle of the bus is chattering there is a chance a device closer to the controller might get more data to the controller non corrupted vs being after the bad device. But the real solution is to fix the bad device to have a healthy bus.

Also if a device is designed to spew data/errors when it has an issue onto the bus it can overwhelm a lower priority level device on the bus.

[Crowz]

Protocol of the I-bus

In BMW vehicles, the protocol for communicating the individual ECUs in the networks is structured according to the following scheme:

Source ID
Identification of the participant who wants to send a message to another BUS user

Length
Length of the complete message (without source ID and length itself)

Destination ID
Identification of the participant to whom the message is sent

Data
payload the message

XOR CRC Checksum
The checksum is used to verify the message. The recipient of the message calculates the checksum and compares it with the one contained in the message.


Now with this packet you can kind of get the idea how this can go sooooo totally wrong if any part of this pattern isnt followed fully.


Some other possibly helpful info I ran across.

Addresses of the bus participants in the I-bus
In the network, each participant is identified by an ID (address), the length is one byte each.
ID
(Hex)

Name of the participant comment

00
General News (1)

18
CD changer Address of the MP3 player

30
SES (voice input)

3B
video module

3F
DIS external diagnostic system

43
Menu screen on-board monitor

50
steering wheel buttons Left side

60
Parking system PDC

68
radio

6A
DSP (sound processor)

7F
GPS module

80
Instrument cluster IKE

A8
Unknown

BB
TV module (in video module)

BF
Light control module LCM

C0
Multi-information display MID not installed

C8
phone

D0
navigation data

E7
Text line in instrument cluster

E8
Unknown

ED
Memory seats

F0
Buttons on-board monitor

FF
General News (2)

The following explains why the dsp quits when the factory head unit is replaced by an aftermarket radio.

Control units that are not standard equipment of the vehicle and can be retrofitted are automatically detected on the bus.
Recognition takes place when a request directed to the control unit is answered in a certain time or the retrofitted device has logged on with an initialization message.
This also applies to the CD changer emulated by the MP3 player.
After switching on the ignition, the radio queries the associated slaves (DSP / CD changer or MP3 player).
The request of the radio must be answered. In addition, the device must send a sign of life at regular intervals.
If this does not happen, the device will be deactivated until the vehicle is restarted.
It is therefore important that the MP3 player responds reliably to requests.
The CD changer is controlled by the radio only. When the CD mode is selected, the radio sends a message to the CD changer to start playback.
The CD changer sends a message back to the radio that starts playback. All other control commands such as CD changes etc. are transmitted in the same way.
The buttons on the on-board monitor and the buttons on the multifunction steering wheel send a message at the press of a button containing the code
of the button and the type of button press (short press, long press and release the button)

[crystalworks]

Originally Posted by Crowz

This page shows you everything you need to know to install the ibus adapter :

BMW IBUS Adapter – Android | Crowz Nest

Note I had the factory nav so this install is exactly like yours except I didn't have dsp which has no effect on how to install the ibus adapter anyways.

Guess I'll go back to this option as it was my original intention and definitely the easiest option for those of us who had nav monitors. Good info on the bus as well. Was pretty sure that was the way it worked. As always, thanks Crowz.

[Overboost]

My thoughts are mixed. I know Crowz has had no problems at all with his but Rolf Resler knows more about the BMW iBus than any of us and he is saying it has issues tapped there, I can only believe him. I would love to hear more from him on those connections.

3.3 Connection to the MID plug (NO RECOMMENDATION !!!!)

3.4 Connection to the blue connector of the on-board monitor (NO RECOMMENDATION !!!!)

[crystalworks]

Originally Posted by Overboost

My thoughts are mixed. I know Crowz has had no problems at all with his but Rolf Resler knows more about the BMW iBus than any of us and he is saying it has issues tapped there, I can only believe him. I would love to hear more from him on those connections.

3.3 Connection to the MID plug (NO RECOMMENDATION !!!!)

3.4 Connection to the blue connector of the on-board monitor (NO RECOMMENDATION !!!!)

I hear that too... but in an effort to avoid running an iBus data wire all the way from the back of the truck and having to pull the interior again... I'm going to first try the board monitor plug, and then the LCM harness. If both of those fail I'll run a new wire from the back.

[Crowz]

Mine has been flawless. No issues at all with it. If my wife cant mess it up since she got it from me that's about as severe of use as it gets

But as mentioned you can always wire it differently later and my method takes two seconds to install.

[PropellerHead]

Originally Posted by Crowz

Mine has been flawless. No issues at all with it. If my wife cant mess it up since she got it from me that's about as severe of use as it gets

Mine was great for a solid year. Then this dance.

Anyway. I am *looking* for the noisy thing that's breaking the fun for everyone, but nothing sees an error. *Sometimes* I get the accumulator error, clear it, and then it comes back. I'm anxious as hell to find out if wiring it closer to the LCM changes the behavior.

[mr_robot]

Since I haven’t installed mine yet and the harness already tapped into the radio plug from AVIN I will just extend those wires during my install.

[PropellerHead]

Originally Posted by mr_robot

Since I haven’t installed mine yet and the harness already tapped into the radio plug from AVIN I will just extend those wires during my install.

Is the Avin set up to use the interface and is already tapped in to the harness? If it is, I'd say use that and see how it works. I'm only planning on the LCM connection to satisfy a curiosity and address a functional issue. If I got an Avin, and it's supposed to work the way they provide it, I'd hit that first. Unless I have the wrong idea of how it's designed.