Does anybody know is it possible to send/ write Canbus messages to the car directly from the Android head unit? And if it is, how to do that?
I have HU MTCE_PX30_MX and some Canbus messages are already sent to the car, so it is possible, I know. But is there any way to sent some specific messages only..?
I think for this you should have a look at MTCCanBus.apk. At some point, a serial connection is opened which seems to be responsible for receiving / sendings CAN Messages. I don't know if the connection goes directly to the CAN-Box, if it is a virtual port that simply sends data to an other software layer or if it goes anywhere else...
This is probably a good starting point.
herb77 said:
I think for this you should have a look at MTCCanBus.apk. At some point, a serial connection is opened which seems to be responsible for receiving / sendings CAN Messages. I don't know if the connection goes directly to the CAN-Box, if it is a virtual port that simply sends data to an other software layer or if it goes anywhere else...
This is probably a good starting point.
Click to expand...
Click to collapse
Thank you for the hint, I will look at it.
Actually I have already "decompiled" HCTCanBus.apk (I guess that this is right apk for MTCE units?) but I have to look it more closely. I am not so familiar with coding...
While a old thread I though I would at least now provide a Answer,
See my github for example code to talk to the CANBOX via the OS and via android calls using the existing mtccanbus.apk and such , Alas i dont know java so cannot help you there , all my work is within the CANBOS unit so far.
Canbus and services
Darkspr1te
@darkspr1te thank you. This is really useful. All I need to do is catch one MTC canbus intent into my app and get it to work, like one of the TPMS tire pressure intents for example. If I can make it work for one, I can make it work for many intents. I have a project that I'm working on and your code will definitely prove helpful !
Any news here? I really want to be able to display CANBUS info usong tasker...
marteline said:
Any news here? I really want to be able to display CANBUS info usong tasker...
Click to expand...
Click to collapse
So get involved
I downloaded @darkspr1te code and encountered some problems compiling that I haven't completely sorted out yet. Thing is that I've been quite busy with other priorities lately but I still want to pursue developing my app.
@darkspr1te did not provide any build/compile notes about the development environment used to develop the code. I'm using the latest version of Android Studio and just working through each issue one at a time. Wish @darkspr1te had used gradle as it would make setting up the build environment much easier .
The code i mentioned is not mine(as mentioned in the post too) , if you want a gradle based then see CANBUS app which is by another author. My current code is what runs on the actual canbus device (raise etc) , I have not produced any android code myself just the MCU code.
Also see this thread for further info on the headunit to canbus protocol CANBUS protocol
@darkspr1te thank you for the suggestions. I guess my referring to it as "your code" was mistaken, sorry about that. I pulled the code from your git repo and just misquoted the original source for the code.
Still regardless of the original author, I just wanted to get the code to compile and work. Maybe I can find the example(s) I needed from the other suggested resources.
Rear little connectors in HU has an 8 pins section used for CANBUS, but only if radio has CANBUS. In that little 8 pins connector section there are 2 pins called TXD and RXD that go to CANBUS box (in my case, Honda Accord 7th, to HVAC buttons frame). I haven't measured signals TXD and RXD that go to CANBUS box and, thus, I don't know if they work at 5 V or 3.3 V. I don't neither know the protocol in these lines. But CANBUS box translates signals in both senses. CANBUS is a multinode trunkline that uses 2.5 V in recessive state and +/- 1 V for dominant. But it is a serial port at radio side.
See pins 36 and 50.
It would be possible to add an Arduino 2560 with 4 serial ports as a gateway, that is, intercepting TXD and RXD with 2 serial ports of 2560 and having 2 additional serial ports to connect another devices. One of them might be an FTDI USB serial to HU and inject and intercept CAN messages from an own application. But it requires to know CAN message format at serial side.
Even better might be to program directly in HU without installing an external element, that must be also programmed. I think there is an hierarchical structure of classes that produces events that can be intercepted. But I don't know how to do it. I have begun to read about Android Automotive but there is no much information about it. The main problem is how to put a car on the table beside a PC with Android Studio.
Here the manual that describes the RS232 side messages of a certain CAN-RS232 converter: https://drive.google.com/file/d/1CKftK1HeclPr9TdSG6DdCFfwmeMjoFIm/view?usp=drivesdk
Interested in protocol, see chapter 2.7.2 and successive. But not all devices must forcely work exactly as this one.
But there is another converter that uses another different message format at RS232 side (around chapter 4): https://drive.google.com/file/d/1CMcJqeHfP0YFG83UOwGMe2EUwyD49_bY/view?usp=drivesdk
It is necessary to sniff TXD and RXD wires or having a manual describing chinese radio CAN message format.
VB6 example: https://drive.google.com/file/d/1CMlDhSCgk9QhxLxvgrERXKX1jOOKXLOo/view?usp=drivesdk
The H/U to CANBOX is 3.3v (default stm32 profile) but the pins used are 5v tolerant. There is already a fully working project plus sources with protocol encode/decode functions at
https://github.com/smartgauges/canbox
@Pacovich also your google drive links require access control so no one can download them.
Related
I saw this product mentioned on infosync, and it got me thinking that with your growing knowledge of the Phone Edition's inner workings that something like this might be possible on the XDA:
PsiLOC+ miniGPS
(in case you don't want to visit the page)... Basically they are using information about which cell towers are in range to trigger events. They give some nice examples, like having an alarm go off when you get close to your train stop (that way even if the train's delayed and you're asleep you still get the "wake-up call" when you're near your destination.) Or how about having the phone turn the volume down (and switch to vibrate) automatically whenever you're in church or your favorite movie theater.
You could do the XDA a great service just making details of how to get at the relevant information (area ID and cell ID) public, if they aren't already...
CellID and other network info
At the lowest layer, there seem to be no AT commands to get network-related information. And at the TAPI layer (the only one an application can easily get to), this information is, as far as we know, unavailable.
We're working on understanding the modem better, and one of the aims of this endavour is precisely this: getting the CellID for location-based stuff.
Stay tuned (but don't hold your breath)
Surely not?
Surely the only communication with the radio stack isn't via AT commands. Is there no low level api, IO ports, DMA, interrupts etc? How, for example, is the voice stream delivered to the radio stack?
Would it be possible to write a kernel mode driver for these services?
I won't teach you to suck eggs, but maybe a few ideas.
Well... As we see it now all communication with the modem may well be multiplexed in one serial 115.200 bps serial stream. We're working on it...
On my Nokia 6210 I've installed Network-monitor. It shows easily this kind of information.
see this:
http://www.logomanager.co.uk/help/Tools/NetMonMenus.html
localization??? it's already there!
look:
http://www1.o2.ie/products_services/location_services
Re: localization??? it's already there!
kimmie said:
http://www1.o2.ie/products_services/location_services
Click to expand...
Click to collapse
These services are network based: i.e. the network knowing where the phone is. This is different than the phone autonomously figuring out where it is, without help from the network.
Depending on the provider, maps with cellIDs may be available.
serial stream.
XDA Developer, I'd like to be involved in the investigation of the modem. This interests me a great deal.
Not hot on hardware, but I can do some dissassembly and stuff like that.
[email protected]
Disassembly would be a lot easier if you set yourself up with a dev system for ATI Nucleus (which I'm told is the embedded OS for the radio stack).
I have a Nucleus setup here but it's geared toward PowerPC as the target. Anybody know what kind of processor is in the radio module? Is the DSP ("TI HERCROM") what's running Nucleus? According to ATI's site all of the dev tools for that port are maintained by TI. The chip has a JTAG interface, so that would make emulation a possibility, and might help. TI's tools for these things are historically free (they want you to buy chips, after all) but I haven't dug any deeper than this right now.
A 4 meg code space is quite a lot to have to wade through, and it's looks like they're using most of it.
Anyone who upgraded their T-Mobile device using the latest update has easy access to the radio stack ROM image, since it lives in the Windows directory after the CE OS upgrade and never gets deleted. There's a file called rsupgrade.cp64 (3.83 MB) which contains the code being squirted into the radio module's ROM by rsupgrade.exe after the first soft-reset.
Hi *,
I'm very new to forum and hardware hacking. I'm also new to android dev (I have done some WP7 development).
I want to write application about radio conditions (RSCP, EcNo) and also wanna to decode ASN.1 messages to get some 3GPP layer 3 messages (RRC). To do that, I suppose that low level access is required.
So, is there any tutorials, guides etc. on how to do that for android devices (I know about android telephony class) or WP7/WP8 devices.
I also know that that is not possible on every device due manufacture restrictions.
I'm interested in Galaxy S(2/3), Nokia Lumia, Nexus, etc (device doesn't need to have qualcom chipset, all i wanna to do that).
I also know that some of companies like ASCOM are working together with chip suppliers for that kind of applications.
So, is it possible to do on market smartphones...
Thanks in advance for answers
Cheers!
TK
It's troublesome thing.
Every modern mobile solution does split into AP (Application Processor) and BP/CP/Modem (Baseband/Call Processor), sometimes these are integrated into one SoC (QC chips) or are splitted into 2 SoCs (like Exynos AP+QC/Infineon CP), on AP there's working ARMLinux with Android platform.
Platform does communicate with RIL HAL (proprietary lib), RIL does communicate with modem through some dedicated HW interface using kernel driver, nowaday its common shared-memory topology with abit of control through UART/GPIOs before RAM-share is set up (modem bootup, assuming AP does startup first, which is case in 2xSoC topology, on QC SoCs modem does startup first and does perform bootup of AP submodules).
The problem is - BP OS is closed source. In best case (rather unlikely) low-level transmission params might being received by RIL from AP but not being passed to platform, then you probably would need to patch RIL binary to expose these values to platform. If these transmission params aren't being transmitted from CP to AP, the easiest (and the ugliest) way to do is trying to find network structures inside of modem OS and pooling them from AP (assuming you've got direct access to all of CP memory). More advanced way would be integrating additional data into BP-RIL interface (modifying both RIL and modem binaries), what then narrows down to "best case".
If you aren't familiar with ARM assembly - analysing modem binary is pretty big task, prepare for at least few weeks of intense reversing.
This is a very interesting question!
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
But then again, I don't think anyone have tried hard enough either. I have tried to a limited extent in my research of the Intel XMM6260 and trying to use some of the Android internal telephony API. Others have managed by hacking the AT command line interpreter, directly in the modem image of some limited versions of the 2xSoC's (like those of Intel/Infineon) used for jailbreaking <4S iPhones. These modem images are "only" 10 MB, whereas the Qualcomm modems "images" consists of 50-60 files and have a size up to 60 MB!! Although we should be able to find the AT command Processor (ATcP) in those...
As I see it today, we only have these options how to get these parameters in the Android eco-system.
1) We believe that the modem AT command interpreter/processor have the capability to provide radio parameters to the outside world. But this direct access often seem to be crippled:
a) by denying local or external terminal (UART) serial-access.
b) by being filtered by the RIL daemons and accompanying RIL libraries
c) by being complicated due to using modified IPC (shared memory) communication, rather than regular serial devices. However, by putting the device into "download/debug" mode, sometimes these devices re-appear!
(This is what ODIN, QPST and other programs does, see (4).)
2) We know that the Android internal phone API can use the following calls to get particular modem "stuff" (including sending AT commands): RIL_OEM_HOOK_RAW and RIL_OEM_HOOK_STR
The problem is that no one seem to know how to use it, nor how it depends on the hardware...
3) We know that the Service Mode's (settings/menu) are displaying many of these parameters, so that the phone OS certainly can get have access to these. So another option is to hack and understand how this is done by the service mode menu and the underlying modem software. This is where reverse engineering would come to its right!
4) We also know that many of the OEM phone debug/repair software, like QPST and QDART (Qualcomm) and "CDMA work-shop" etc. have full access to these variables as well...
Actually, if you're on a Qualcomm based device and can put it into QXDM mode, you can have all radio data to be output to the QXDM (3.12.754) software and possibly interface API. Thus... if we can understand the handshake and protocol they use we should eventually be able to make an app that can fetch this data as well...
Thx for your answers!
It looks like I need many hours to investigate and learn! Sound like fun, hope it will be...
I hope that soon I'll post something new on this thread about question.
Thx and hear ya!
Little update: Regarding radio conditions, here is telephony API http://developer.android.com/reference/android/telephony/package-summary.html and here is Signal strength class http://developer.android.com/reference/android/telephony/SignalStrength.html!
So I have these information (at least I hope so, because I don't have device for testing and I don't have dev environment set yet).
Also, regarding WP7 Samsung devices: there is samsung app called Diagnosis, where you can access root/debug screen in Test Mode... I was looking little into that app (I have unlocked Samsung Omnia W device), and there are very interesting informations, like list of neighbour cells with CellID and signal strength and many others (Handover test, antenna/ADC, RRC state, Tx Channel, Tx Power, EcIo, RSCP, L1 (looking now it's PCH_Sleep value ??), etc)
I need that kind of information + need to find way for decode L3 messages like RRC and RLC. From L3 you can find many other information (RAB establishment, IRAT handover, all 3GPP information element for GSM/WCDMA/LTE and so on!)...
hi *,
What about Gobi platform and GOBI dev?
BR
TheKrigla said:
hi *,
What about Gobi platform and GOBI dev?
BR
Click to expand...
Click to collapse
Hi, i was just looking for GOBI, too.
But they only show 4 Devices, with the Gobi-Modem inside:
qualcomm.com/gobi/products/finder?type=Smartphones
But there are buid in a few UMTS/USB-Sticks, Mobile Hotspots, a Router and some Notebooks (SubNotebooks),
Not bad, if you can use it as an external device, like the mobile router.
So it looks like a very special solution.
Did somebody check the HTC, Motorola or Samsung SDK ?
I am also trying to get low network info, and it looks like AT commands that exist (at least on my Samsung S3) do not provide this information. So I think emulating what QXDM does is the secret sauce... but that's hard
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
E:V:A said:
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
Click to expand...
Click to collapse
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Chipset access
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
enigma99a said:
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Click to expand...
Click to collapse
mknair said:
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
Click to expand...
Click to collapse
Thanks.
http://www.swissqual.com/
Probably nothing special. What is special, is that they have full access to all their documentation. If you can download their white papers and the Android app, I'll tell you how they do it!
Is it possible to connect something like a 4G dongle to the usb port to create a roaming RF scanner and get the RSCP ECIO details from that? It's a bit mental but it doesn't look like we will be able to get this detail from the phone without paying the tens of thousands for the documentation anytime soon...
I tried to connect a Sierra Wireless device which can provide this info but I cannot seem to compile the module against the kernel.
I got QMI talking just fine on android 100%. But I need layer 1 info etc as well (DIAG)... Qualcomm docs look easy enough for the packet structure but now i just need access... And I'm totally stuck. USB is one way, but isn't there to get access locally? Like through UART or some other means? I believe all communication goes to the /dev/diag device but so far I have not been able to get access
E:V:A said:
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
Click to expand...
Click to collapse
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Any thought about sharing solution?? Not cool man...
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
E:V:A said:
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
Click to expand...
Click to collapse
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Hi at all!! My hero, enigma99 please tell me (or who knows)!!
I'm developing a app with SDK that use the java methods of classes like SignalStrenght and Telephony. But those methods dont work very well. (they are slow, and in much smartphone dont return the Ec/Io)
Do you think if in 3g tecnhology (UMTS, HSPA) the modem part always returns all measure (RSCP and Ec/Io)??
What's the way to follow for return this values? recompiling kernel? programming with NDK?
enigma99a said:
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Click to expand...
Click to collapse
Is this for sale yet? Curious minds would like to know.
Hi guys, I've been an avid reader of the xda forum, and it's great, so far it has been an awesome source of knowledge, however up until now I had found everything I needed...
Long story short, I want to be able to use the sensors in my smartphone (Rooted Moto G XT1032, 16 GB) in the open source software Processing. Could somebody please point me in the right direction?
Basically I want to:
Connect my phone to my PC via BT or WiFi
Read the value of the sensors within my phone and transmit them to my PC
Somehow read those values in Processing and create nice graphs and stuff
I know how to program Processing, I've looked into the Amarino Project, but it does require the Arduino Part, and I know how to interface Arduino and Processing (I've done some PID control and other stuff with those), but I want to skip the whole Arduino part (at least for now).
Could somebody please point me in the right direction?
Thanks in advance, cheers!
Update 17/09/2014: Currently looking into the SensoDuino project, which apparently will solve my problems in the Android Front.
I tested it following the video in the main page of the project in the part Pairing and Establishing a Serial Connection between Windows 7 and SensoDuino (sorry I still can't post links), I have been able to read the data using Tera Term
Just mind the COM ports, and that you are actually transmitting over bluetooth, you can check this in the services tab of the properties of the paired device within Windows (If anybody wonders why not Linux, which I use the most, in which I do my main work and in which this would be pretty much a native feature, I intend to use this with a Windows Only Software)
Special thanks to TheBeano!
P.S. Depending on what the rules of this forum regarding solved threads are, I'll either update or publish whatever the outcome of this project is, cheers!
Hectormd said:
Hi guys, I've been an avid reader of the xda forum, and it's great, so far it has been an awesome source of knowledge, however up until now I had found everything I needed...
Long story short, I want to be able to use the sensors in my smartphone (Rooted Moto G XT1032, 16 GB) in the open source software Processing. Could somebody please point me in the right direction?
Click to expand...
Click to collapse
Look at SensoDuino, they have a demo of connecting to Windows 7 via Bluetooth serial. Once you have a Bluetooth serial connection you can use Processing's serial comms to read the phone sensors. You could do the same sort of thing with Amarino, that is just read from the serial port, but it might be more work to decode the binary protocol that it uses from Processing. Sensoduino sends ASCII I think.
TheBeano said:
Look at SensoDuino, they have a demo of connecting to Windows 7 via Bluetooth serial. Once you have a Bluetooth serial connection you can use Processing's serial comms to read the phone sensors. You could do the same sort of thing with Amarino, that is just read from the serial port, but it might be more work to decode the binary protocol that it uses from Processing. Sensoduino sends ASCII I think.
Click to expand...
Click to collapse
Thanks a lot, it looks exactly like the thing that could fulfil my needs.
I'll update this post or publish whatever I come up with cheers, and thanks again!
Background:
- Presently there doesn't seem to be a method of relaying information from our Android head units to OEM Instrument cluster displays (turn directions, speedcam alerts, OBD/Torque info, callerid, message alerts, etc.).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
- I've begun working on a system to relay and display such information from an android head unit to the instrument cluster display.
- As I have little/no development experience I've built current functionality using Tasker and associated plugins (Notification Listener, AutoRemote, etc.).
How it Works:
1. Turn by Turn Directions:
- When navigating with Google Maps a persistent notification is created in the notification drawer. This notification updates with simplified navigation information (next turn direction, distance to next turn, additional description [e.g. turn right onto random street], time/distance to destination, estimated arrival time).
-> The Tasker plugin 'Notification Listener' is able to track and extract information from this notification in real time.
-> A Tasker task utilises pattern matching to determine the main navigation action (Right Turn, Left Turn, Straight, Merge, U-Turn, Roundabout, etc.).
-> According to the pattern matching, IF then ELSE statements initiate additional actions, splitting the notification text to set the relevant parts of the text into different variables.
-> These variables are either directly displayed in a Tasker Scene, or their contents alter other elements (visibility of scene elements, Turn Icons).
-> One variable dictates the Turn Icon displayed in the Tasker Scene. For Example: When a right turn is detected by pattern matching, a variable is set to the file path of a right turn icon image. The same variable is changed according to the next turn direction. A single image in Tasker is set to display the image of that variable (and thus shows the next turn icon).
Current Development Status:
WORKING
a. Recognises and shows: - When no destination is entered in Google Maps - Message to continue onto a road to begin journey - Right & Left Turn icons - Straight icon - U-Turn icon.
b. Distance to next turn.
REQUIRED
a. Icons and messages to indicate: - Roundabout exits - Merge onto... - Arrival notification - Other unusual turn/navigation notifications.
b. Time to destination (I tried to integrate this but the extra split operation seemed to to increase lag in display of more important information such as distance to the next turn). I'm sure there's a good workaround for this.
c. Additional turn information text (e.g. turn right onto random street). This is an easy task, will implement soon.
d. Improvement of navigation information update frequency - Presently when there are frequent updates (e.g. when approaching a next turn at high speed the distance to next turn changes more frequently) there can be a minor lag between the next turn information in google maps (and notification) and its display in the Tasker Scene. Generally it's working fine though.
2. Speed Camera Alerts:
- Speed Camera information is loaded onto an app called 'Speed Trap Pro' (found on Play Store).
--> A Tasker plugin named 'Auto Speed Trap' alters Tasker variables (Distance to Camera, Camera type, etc.) when approaching a Speed Camera (GPS based).
--> A Tasker task is set to recognise when user is approaching a Speed Camera and temporarily change the image path of the turn indicator to a Speed Camera icon in the Tasker Scene (until speed camera is passed). Distance to the Speed Camera is also displayed.
WORKING
All implemented.
REQUIRED
Text showing distance to the next speed cam does not update frequently enough/smoothly.
3. Music Player Information:
- When a song is changed on the head unit, artist and song information can be temporarily shown in the area that usually shows next turn text (e.g. instead of 'turn right onto random street' it would show 'Led Zeppelin - Stairway to Heaven').
WORKING
Working.
REQUIRED
Could be developed to scroll song information when either the Artist or Song name is too long to fit on the screen.
4. Caller ID:
- This should display the caller ID of incoming calls (in the same area as the music player information).
- I'm not sure whether this information could be drawn directly from the head unit or if it would have to be relayed from the user's phone to the instrument cluster display client (described below).
- This can rely on Notification Listener and AutoRemote.
- when incoming call —> center media control answers.
NOT IMPLEMENTED
5. Message Alerts:
- This should display contact information and message text for new messages (SMS, Whatsapp, etc.).
- should save last 5 messages (only received during driving) —> allow scroll through under messaging tab —> allow reply (long press center button).
- Similar challenges to Call ID.
NOT IMPLEMENTED
6. OBD Information:
- This would draw real time vehicle information from a bluetooth OBD dongle and display it on the cluster display (e.g. 0-60 times, fuel consumption, etc.).
- Torque is a great Android app that interprets information from OBD data.
-> Presently there is no dedicated Tasker plugin for Torque, or other OBD apps, however a solution might be found in Torque's API:
http://torque-bhp.com/wiki/PluginDocumentation
-> Preferably Torque OBD information would be updated in real time.
7. Radar Detector Integration:
- I own a Valentine V1 Radar Detector. The Valentine V1 is able to connect to Android over Bluetooth (SPP).
- There is an API. It would be nice to integrate radar detection alerts into the Tasker Scene’s UI (like with regular speedcam alerts).
- Alternatively there is an app called YaV1 that can serve heads up alerts.
7. USER INTERFACE:
- Bluetooth or CANBUS steering wheel controls can be used to navigate the interface.
(e.g. http://www.satechi.net/index.php/satechi-bluetooth-button-series-media-button).
- These would be remapped to Tasker tasks to run different actions according to which screen is in view.
- Below is my proposed UI/UX:
- The interface requires implementation/ improvement and can be adapted for your particular cars.
8. SECOND DISPLAY SOFTWARE:
- All previous functions are presently running locally (i.e. on the device on which Google Maps Navigation/ Music Playing/ Calls/ Messages are taking placed [the head unit]).
- This information must be relayed to the console display.
- My present plan is to relay this information to a second android phone/client.
-> This could be done using the Tasker plugin 'AutoRemote'. AutoRemote is able to send Tasker variables from one device to another. This can work over Bluetooth, a local WIFI network, or online.
- It is important to devise this system in a way that will minimise latency between triggering of notifications on the Headunit or user phone, and their appearance on the instrument cluster display. This is particularly important for navigation information.
-> In order to achieve this, as few as possible variables should be sent from the head unit. Any actions that increase the number of the variables should take place on the client device rather than the head unit.
There are 2 ways in which this can be implemented (regarding navigation turn directions):
a. Google maps notifications can be extracted by the head unit, set as Tasker variables and sent to the client Android's Tasker over Bluetooth/Wifi.
-> Split actions will be applied on the client device.
-> The scene will run on the client android according to resultant variable information.
ADVANTAGES: - Less requirements from the client device.
DISADVANTAGES: - Latency may not be acceptable.
b. When a destination address is set in Google Maps its coordinates are set in a log file (I think! If not then the address can be processed into coordinates by a geocoder). These coordinates can be sent from the head unit to the client Android and set to launch Google Maps navigation on the client with the same destination as the head unit.
ADVANTAGES: - Many less variables will need to be sent by AutoNotification - Latency should be far lower.
DISADVANTAGES: -The client device will need to have a functioning GPS, to be positioned in a place where it functions (less obstructions), and to have a functioning internet connection.
THOUGHTS: I would tend towards option B.
SYSTEM MAP:
Below is a proposed system map. One potential problem is that there are multiple devices (OBD + Radar detector + Head Unit > Client Connection (AutoRemote)) connecting to the same device over the same Bluetooth profile (SPP). This doesn’t work for all devices - will have to test to find out.
An alternative method would use a 3g WIFI Modem to provide data to the devices and to transfer data over Autoremote. This would free the Head Unit > Android Client connection from relying on the SPP Bluetooth Profile. The OBD dongle could then be connected to the Head Unit, and the Radar detector connected to the Android Client.
8. SECOND DISPLAY HARDWARE:
- Once head unit information has been transferred and processed into a Tasker Scene on the Android client, it needs to be displayed on the instrument cluster display.
-> This can be implemented in 2 ways:
1. Replace the existing instrument panel display with a small display that can connect to an android phone/raspberry pi over MHL/Slimport/HDMI/VGA.
-> This is the smallest display I could find with a tested HDMI input. It is larger than the OEM cluster display on a VW so may cause problems:
http://www.buydisplay.com/default/er-tftv043-4
2. Output CanBus Information to the existing display (seems like it may be possible using this adaptor:
https://www.kickstarter.com/projects/etx/canbus-triple-the-car-hacking-platform).
THOUGHTS: I have decided to implement option A. This is not the smoothest solution as it requires replacement of instrument cluster display, but as I don't have any development experience, this is simply what I am able to achieve.
Where Do We Start:
1. Let me know your thoughts on the project.
2. I've attached Tasker project files and icons:
a. Import Tasker Project: https://dl.dropboxusercontent.com/u/4719739/Car_Present.prj.xml
b. Download icons onto your device: https://dl.dropboxusercontent.com/u/4719739/icons.zip
c. Change 'DIRECTIONWATCH' and 'SPEEDCAMIMAGE' variables: Set 'Notification Listener' Task variables to Right, Left, Straight, U-Turn icons, ' No Destination' to a vehicle icon of your choice (mine is for VW), 'Speedtrap' to the Speedtrap icon and 'Cancel Speedtrap' to the blank PNG. link the location you place each of the attached icons (different turns, vehicle logo, speedtrap, blank png for cancel speedtrap).
Install the following apps and Tasker plugins:
- Notification Listener: https://play.google.com/store/apps/details?id=com.balda.notificationlistener&hl=en
- Speed Trap Pro - optional if you want speed camera alert: https://play.google.com/store/apps/details?id=com.balda.speedtrappro
- Auto Speed Trap - as above: https://play.google.com/store/apps/details?id=com.balda.autospeedtrap
d. Launch the task 'Scene'.
e. Enter a destination and begin navigation in Google Maps.
- Let me know how it works.
- Feel free to discuss and chip in however you can.
Very cool project mate :good:
I dont have a cluster display or I would definitely be giving this a go!
Extremely cool idea - once I get everything else up and running on the unit as I want it, I'll definitely try this!
Hi,
Nice idea but it will be kind of diificult. I was also thinking myself that that can be acchived because we have all the information. But sending them back to the cluster is the hard part.
My Experience : VW cluster, Huifei with CanBus support.
There is already the needed function in one of the MTCA pps to send some information.
In my cluster, I can see : Music track / length, "Video" if a video is played, SD Card xhen music comes from SD Card, Radio frequency .....
The apps, depending on your choice in the Settings (Canbus settings) is sending information trought the MCU I think.
There are some functions like SendRadio(), SendMusic().....
That is the bad news because if we want to add some custom info, maybe we can't because we would have to modify also MCU img.
I've seen on other forums some guys successfully displaying all kind of information on their cluster, but it was a more hardware specific device (CANBUS + RS232.....).
Definitely possible, but a lot of work.
dc5daft said:
Very cool project mate :good:
I dont have a cluster display or I would definitely be giving this a go!
Click to expand...
Click to collapse
Thanks. The other option is to use it on a second phone and tape it infront of the steering wheel. Would still function as a second display for all vital information.
Nova8316 said:
Hi,
Nice idea but it will be kind of diificult. I was also thinking myself that that can be acchived because we have all the information. But sending them back to the cluster is the hard part.
My Experience : VW cluster, Huifei with CanBus support.
There is already the needed function in one of the MTCA pps to send some information.
In my cluster, I can see : Music track / length, "Video" if a video is played, SD Card xhen music comes from SD Card, Radio frequency .....
The apps, depending on your choice in the Settings (Canbus settings) is sending information trought the MCU I think.
There are some functions like SendRadio(), SendMusic().....
That is the bad news because if we want to add some custom info, maybe we can't because we would have to modify also MCU img.
I've seen on other forums some guys successfully displaying all kind of information on their cluster, but it was a more hardware specific device (CANBUS + RS232.....).
Definitely possible, but a lot of work.
Click to expand...
Click to collapse
True. The cluster part is most difficult (and beyond my abilities). For the first stage I intend to connect an old phone to an external 3inch lcd and place it instead of the cluster display.The old phone will act as the client.
On a vw its pretty easy to take apart the cluster. Only problem might be if the lcd doesn't fit in place of the cluster display. Will take it apart soon to check.
One part I could use help with is the OBD/Torque data extraction. Has anyone managed to interface with torque that could extract data to Tasker?
I'll upload an updated version of the navigation and interface later today.
As Nova8316 says, this is supported already on the MTCB head units via the "Car service" app, which appears or disappears depending on what CAN Bus setting the MCU is on, support is a bit patchy - some cars are not supported at all and some only partially, mainly the most popular cars are supposted VW Group for instance.
The MCU basically talks to the CAN Bus system via the CAN Bus high/Tx and CAN Bus Low/Rx lines and/or the CAN Bus adapter. Would it not be easier to try and make this work for your car/more cars by trying to add functionality to the existing set up ?
typos1 said:
As Nova8316 says, this is supported already on the MTCB head units via the "Car service" app, which appears or disappears depending on what CAN Bus setting the MCU is on, support is a bit patchy - some cars are not supported at all and some only partially, mainly the most popular cars are supposted VW Group for instance.
The MCU basically talks to the CAN Bus system via the CAN Bus high/Tx and CAN Bus Low/Rx lines and/or the CAN Bus adapter. Would it not be easier to try and make this work for your car/more cars by trying to add functionality to the existing set up ?
Click to expand...
Click to collapse
Hi, sorry for super late reply. Busy months with work.
1. Some of the features seem to be supported by the Car Service app, but not all. Are navigation directions supported? This is most important for me.
2. Additionally, for me at least, my cluster display is old and doesn't support all functionality. This implementation would allow for a visually appealing display that supports infinite customisation (adding speed camera alerts other).
3. I'd love to add the rest of the features via support of the existing display, I'm not a programmer, my abilities are presently limited to Tasker.
- If anyone wants to help I can upload my latest implementation soon. I'm working on adding simple call and message alerts.
I've decided to trigger Google Maps on the secondary display connected android device, rather than passing turn notifications one by one over Bluetooth. The way it should work is that when you enter a destination into Google Maps on the Head Unit --> the destination information will automatically be extracted and sent via Tasker and Autoremote to the secondary display connected android device.
--> My problem here is that I haven't been able to extract current destination information from Google Maps. Can anyone suggest a way of doing this?
I've tried a suggestion to run the following script:
sqlite3 /data/data/com.google.android.apps.maps/databases/da_destination_history "select dest_address from destination_history order by time desc limit 1;"
Unfortunately this script seems dated as I can't find the database da_destination_history on the latest iteration of Gmaps. Instead the following databases are found under google maps:
ue3.db-journal, ue3.db, gmm_myplaces.db, gmm_storage.db, gmm_storage.db-journal, gmm_offline{some long number].db-wal, gmm_offline{some long number].db-shm, some more..
Out of these files, gmm_storage.db does seem to contain the current destination address, but I can't find a way of identifying it as such within the file, thereby allowing operations to recognise and extract the destination address.
Any help would be greatly appreciated.
Thanks.
I guess if you dont have the skills to code and your car display doesnt support what you want then this is the way to go.
typos1 said:
I guess if you dont have the sills to code and your car display doesnt support what you want then this is the way to go.
Click to expand...
Click to collapse
I've got a VW Passat 2012 and would gladly help with any testing needed. Not sure how helpful I can be with development but can try stuff out.
Nova8316 said:
Hi,
Nice idea but it will be kind of diificult. I was also thinking myself that that can be acchived because we have all the information. But sending them back to the cluster is the hard part.
My Experience : VW cluster, Huifei with CanBus support.
There is already the needed function in one of the MTCA pps to send some information.
In my cluster, I can see : Music track / length, "Video" if a video is played, SD Card xhen music comes from SD Card, Radio frequency .....
The apps, depending on your choice in the Settings (Canbus settings) is sending information trought the MCU I think.
There are some functions like SendRadio(), SendMusic().....
That is the bad news because if we want to add some custom info, maybe we can't because we would have to modify also MCU img.
I've seen on other forums some guys successfully displaying all kind of information on their cluster, but it was a more hardware specific device (CANBUS + RS232.....).
Definitely possible, but a lot of work.
Click to expand...
Click to collapse
Hi,
I did some research and i think that the MCU has nothing or little to do with sending and receiving messages/info from/to the car. The main unit communicates with the canbus converter using serial rx/TX at a 38400bps. This is where the mcu gets out of the game. The serial protocol between the HU and the canbus decoder is the same for all the HUs and canbus decoders. According to this all the hard job is done on the canbus decoder. The more PIDs that it supports, the more the HU can show you!
I am working on the same thing for my Mercedes car. I need 3 things to do:
1. Interpret the canbus PIDs.
2. Interpret the serial protocol between the HU and the canbus converter.
3. Write an app that listens to the serial port that the HU is connected to and start playing with messages.
On the above the only difference for various cars is the supported canbus PIDs which are by no way the same between different car brands and sometimes between car models.
So at the end i believe that i will build my own canbus converter for my car! (i have to re invent the wheel)
If anyone has info about the serial protocol between the HU and the canbus decoder and willing to share, it would help a lot.
Regards
psychegr said:
Hi,
I did some research and i think that the MCU has nothing or little to do with sending and receiving messages/info from/to the car. The main unit communicates with the canbus converter using serial rx/TX at a 38400bps. This is where the mcu gets out of the game. The serial protocol between the HU and the canbus decoder is the same for all the HUs and canbus decoders. According to this all the hard job is done on the canbus decoder. The more PIDs that it supports, the more the HU can show you!
I am working on the same thing for my Mercedes car. I need 3 things to do:
1. Interpret the canbus PIDs.
2. Interpret the serial protocol between the HU and the canbus converter.
3. Write an app that listens to the serial port that the HU is connected to and start playing with messages.
On the above the only difference for various cars is the supported canbus PIDs which are by no way the same between different car brands and sometimes between car models.
So at the end i believe that i will build my own canbus converter for my car! (i have to re invent the wheel)
If anyone has info about the serial protocol between the HU and the canbus decoder and willing to share, it would help a lot.
Regards
Click to expand...
Click to collapse
You can try to decompile the Vehicle.apk file which only read some PID from the canubus.
You can dmsg with a terminal and see that one of the devtty is outputting some strings.
Also, the Music app is sending the info through the MtcCanbusManager. This program is the one that send the correct strings to the canbus decoder.
If you go with a standalone canbus decoder, you would do more things.
Nova8316 said:
You can try to decompile the Vehicle.apk file which only read some PID from the canubus.
You can dmsg with a terminal and see that one of the devtty is outputting some strings.
Also, the Music app is sending the info through the MtcCanbusManager. This program is the one that send the correct strings to the canbus decoder.
If you go with a standalone canbus decoder, you would do more things.
Click to expand...
Click to collapse
Yes i already saw that the canbus decoder works with strings. Mtccanbusmanager does all the job sending/receiving the strings and broadcasting the messages to the correct apps.
I cant find the Vehicle.apk as i am looking for it almost a month now and noone seems to be able to post it on the forum. MTCControlInfo.apk is the app that i have decompiled. Is it the same?
psychegr said:
Yes i already saw that the canbus decoder works with strings. Mtccanbusmanager does all the job sending/receiving the strings and broadcasting the messages to the correct apps.
I cant find the Vehicle.apk as i am looking for it almost a month now and noone seems to be able to post it on the forum. MTCControlInfo.apk is the app that i have decompiled. Is it the same?
Click to expand...
Click to collapse
Its in all ROMs, so you should be able to find it somewhere.
I posted in the other thread. This might help:
http://forum.xda-developers.com/showpost.php?p=58749562&postcount=8564
RWerksman said:
I posted in the other thread. This might help:
http://forum.xda-developers.com/showpost.php?p=58749562&postcount=8564
Click to expand...
Click to collapse
Maybe you should tell him where you got it from so he can get the latest one, the one in your link is over a year old.
typos1 said:
Maybe you should tell him where you got it from so he can get the latest one, the one in your link is over a year old.
Click to expand...
Click to collapse
Is this supposed to be the "Vehicle.apk"?
psychegr said:
Is this supposed to be the "Vehicle.apk"?
Click to expand...
Click to collapse
There are quite a few different apks like vehicle.apk, control settings.apk, etc, they appear and disappear depending on what CAN Bus setting you have the unit on in factory settings, but if you get the latest ROM you should be able extract all of them from it.
(I ll get round to replying to your pm soon BTW, been very busy)
i realy like this project.. but i whant to go a step furter.
what if we juse a cheap ass android smartwatch. and make from that a mini HUD. MY peugeot have black small display for the warning ligts. like a 4 by 5 cm. when you put a little HUD foly on it an project the smartwatch to it you have a mini HUD. with you tricks here it must work.
maby an idea?
Has this gone any further? I just bought a 2016 VW GLI, and I am not happy that the turn by turn does not show up in the MFD in the cluster. There HAS to be a way...
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?