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 ?
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.
I have written code using tcl/tk for quite some time and I would not have much problem writing this code (actually, I have written a very similar code before) but since Android is Java I will have to educate myself before I try to build this app. What I am trying to find out is how much will I have to educate myself before I can pull this thru. Learning to write code in tcl/tc did not took me long and I actually did a lot of learning while writing code so again, not having experience in java I am seeking the feed back of those that are currently way ahead of me to give me a better feel of what I am getting into... :victory:
This app will be based in a program built for windows. I have thru the years ask the vendor if they are going to port it to android and I always get the same response, "in a few months"...
Here is what I am looking forward to build...
Overview
Need to create an Android app that will consist of an UI and data processing terminal to communicate with a serial device. The terminal will be capable of sending commands to the serial device to gather information, process the information and then display it in human understandable terms.
Goals
Basic program:
* Create communication with a FTDI chip at 1200 Baud Rate, 8 data bits, No Parity, 1 stop bits and xon/xoff flow control, I have prove it to work with no control since the amount and rate of data is so small.
* Capable to send hex ascci commands, receive a dump in hex ascci then translate that hex ascci dump into decimal format for processing. The serial device communication and hardware cannot be changed. Most all commands are set but there is one command that the value will change depending on previous data found.
Example of communication:
send :000000037D (status command)
Response:
Hex/ascii -> decimal
:0401010C2A0094 -> 4 1 1 12 42 0 148
:0401010C9A0489 -> 4 1 1 12 154 4 137
In this example column 2, 3, 5 and 6 has the data I need and will have to process to display the final values.
* Status command should have option to be controlled with a timer with options for 1, 5, 20, 40 sec and Timer off. There should be a button on the UI to send that status command, also, the ability in the future for the command to be microphone driven (x amplitude loud noise will trigger command).
UI:
* Dark colors to keep the display from eating up the battery.
* Should turn off the display every 10 seconds and should come up on new data, mic driven or phone shake.
* Should have a display where the last data numbers will be displayed. Also to have the ability to create a second larger display with the same last data numbers.
* Need 8 buttons for commands, drop down menu for settings (timer settings) and exit button.
* There should be a space (table) to display data, up to 99 records. It should look more like a excel spread sheet with just 2 column. These columns will bet the data location and the data itself. The table should be able to hold about XX amount of records, if it gets larger then a scroll bar should be used to navigate up and down the table.
Enhanced program
Display altitude/barometric pressure on request(capable phones).
Future:
Right now the device talks to the computer via a serial/usb dongle but I am planning to build the hardware to make it Bluetooth capable but in very few odd instances I might have to run it with the dongle due to the distance between the device and the phone might exceed the most common 30 feet Bluetooth maximum distance.
Im tired of taking my pc to a dusty and pc unfriendly environment so I have decided to take the plunge and build the app myself. Learning Java and android will be beneficial as I can see me in the future building more apps for personal use .
As it is now I can control this device using a hyper-terminal in my Samsung Note. Problem is having to type the commands manually, getting the responses back, translating those hex responses to decimal then building the response... too much work by hand...
Currently im using Slick USB Serial Terminal. Although they have a paid version that could help with the commands it will still leave me with processing the response by hand. It is useful when all I want is to advance the display on the device as it is the most used command but still at times it is imperative to get the status from the system and I am back to square one. And if I wanted a full status report It would take me nearly an hour to process by hand...
I have bought these books:
Java All-In-One for Dummies 3rd edition.
Programing Android, O'Reilly, 2nd edition.
Beginning Android 4, Application Development, Wei-Meng Lee, seems to be 1st edition.
Android application development for java programers, James C Sheusi, also seems to be 1st edition.
Anyone care to comment or recommend a book or a website?
Thanks everyone! You will be seeing much more of me as soon as I start having questions!!! lol!
Is my English really that bad? lol!!!
kinda hard to believe no one can answer this question here. moving on.
Probably this that you may be looking for.
Save time on re-inventing the wheels, or you can decompile theirs.
one of the hyperterminals I been using provides their source so Im not too worried about that. I did not knew you could decompile and app. Anyways, thanks for your reply.
Convert rescued phones to "wireless user interfaces" (remove phone & market cruft)
I'm looking for pointers to suitable distributions to determine the feasibility of "downgrading" older, rescued phones to "wireless GUI appliances". On the one hand, to estimate the scale of the effort that will be involved. On the other hand, to identify the "most promising" devices to go in search of (these will have been donated/scrapped devices -- beggars can't be too choosey!)
How complete are the distributions? How much is hidden, embedded in "blobs"? I'd like to discard all of the code associated with the phone, GPS and much of the user interface and just build up from the kernel and device drivers (display, touchpad, buttons, microphone, speaker, WiFi, BT, etc.)
The goal, here, is to turn the phones into appliances that have no value besides in the system to which they are mated (i.e., walk off with one and you've basically got a paperweight as it is no longer usable as a phone) and to wire-down the user interface to a single, specific application.
[I've been hacking (BSD) kernels for 25 years and writing OSs and drivers for longer still (but, usually for hardware that I have designed) so I just need a shove in the right, general direction.]
Thanks!
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.