iBUS installation location

[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.