08-03-2013, 06:48 PM
Join Date: Dec 2012
Location: Kansas City, MO
My Ride: 2004 325i
Yes. Here's how to do it:
Originally Posted by CTRob
Has Pain break or anyone else any joy figuring out the random boot sequence?
Get the one with the shortest duration. 0-40 seconds.
Red = 12V+
White = Ground
Yellow = "Common" Connection for Relay
Brown = "Normally On" Connection for Relay
Mine had this color layout, and the Green is not used:
Find your red box that attaches to your radio. There's a small green wire coming from it. Cut it in half, connect one side to the Yellow, and one side to the Brown on the Timer Relay. Next to the green wire from the red box, there are red and black wires. These are 12V+ and ground, respectively. Use those for your other connections to the Timer Relay. Red to Red, Black to White. Then, there's a potentiometer dial on the Timer Relay. Turn it all the way to the right. That's 0s. Back it off just a little bit to increase the delay. You're looking for about an 8-9 second delay, so that the radio and CANBUS adapter have time to power on fully before any signals are sent to the CANBUS.
The only way to resolve that issue is to give it internet access. If you can use wifi tethering of some sort to give it 'net access via your phone, then it'll update the time automagically. If not, then you're really not utilizing the Android side in the best way. Here's what I do:
Originally Posted by HighxTech
Anyone have a possible fix for the android side resetting the time every time you turn the unit off? other then the random boot sequence and horrible visibility in the sun that seems to be my only other problem. Perhaps theres an update or something like a CMOS battery on the android board?
Android Phone + Llama + Bluetooth tethered to the non-android side of the radio.
Set Llama to start Wifi tethering any time I'm connected to "Car Kit" over Bluetooth, and stop Wifi tethering any time I'm disconnected from "Car Kit" over Bluetooth.
For the framework, I decompiled it, modified the .smali and recompiled it. I followed the directions from someone else who did a very similar GPS speed "fix" for a chinese tablet. It was essentially a find and replace job inside of the .smali file, within the framework.jar, that tells it how to calculate the speed.
Originally Posted by vilord
Painbreak... how did you go about building that framework jar/apk? Did you build from source, or did you hack it out with a hex editor?
The location accuracy that's missing from google maps... how did you discover that it wasn't generating this data?
A few years back I helped to write the GPS driver for another phone, and for the location accuracy, we just generated it using an algorithm based on comparing location and velocity and the rates of change of both. It was a hack, but it was enough...
Would it be enough to 'fake' it, and in the framework pretend that the usb driver always says "2 meters" whenever it has a fix?
I honestly haven't looked at the framework code in a couple years, but I'm willing to hack it out for a bit.
Picking up my E91 tomorrow or the next day, and a 4.x B090 (as far as i've read, a copy of the B046?) will be on order shortly afterwards.
For the accuracy data, I used a GPS status app that reports accuracy data, and I decompiled the Google Maps app (specifically the com.google.android.maps.driveabout portion) and I can see that it disables turn-by-turn navigation based on the accuracy. It requires 'ACCURACY_FINE' which is defined somewhere as being below some particular meter integer. It's been months and months since I've looked into any of this, so I may not be 100% accurate anymore. But yes, I think a "hack" of the GPS driver to tell us that it's always accurate within say, 10 meters, would return 'ACCURACY_FINE' as being true.
Last edited by PainBreak; 08-03-2013 at 06:55 PM.