[THINK TANK] Enabling the Nexus One FM radio ... - Nexus One Android Development

So I've been looking through the Desire on Nexus One ROM files, and determine a few discoveries with the FM Receiver on the N1.
1. It's present, and works partially (I can scan and get a list of good FM stations in my area)
2. Its controlled via the i2c bus off the snapdragon
3. HTC abandoned using BlueZ on the Desire, and cooked up a custom BT stack (this is at least partially contained in the file /system/bin/btld)
4. Its on the BCM4538 chip, not on the QSD8260 (that being said, looking at the Bravo/Desire kernel source, the QSD8260 is used for part of the audio path.
5. The custom BT stack used on the Desire controls the FM radio at least in part, this is also likely why Bluetooth doesn't work on these ROMs fully.
Here's a bit from the logcat:
I/BTL_IFC ( 578): btl_ifc_ctrl_rx: [BTL_IFC CTRL] recv BTLIF_FM_SEARCH (FM) 10 pbytes (hdl 151)
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): decodePendingEvent: Event ID: 4366
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): enqueuePendingEvent: event ID: 3, ATTACHING THREAD
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): enqueuePendingEvent: THREAD ATTACHED OK
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): [JNI] - TRANSMITTING EVENT UP : event = 3
I/BTAPP_FM( 1086): BTAPP_FM: btui_fm_cback: 3
I/BTAPP_FM( 1086): BTAPP_FM: BTA_FM_SEARCH_CMPL_EVT
I/BTAPP_FM( 1086): btapp_fm_volume_control = 176
I/BTAPP_FM( 1086): BTAPP_FM: clear_af_info
I/BTL-IFS ( 1086): send_ctrl_msg: [BTL_IFS CTRL] send UNKNOWN MSG ID (FM) 12 pbytes (hdl 15)
I/BTL_IFC ( 578): btl_ifc_ctrl_rx: [BTL_IFC CTRL] recv BTLIF_FM_SEARCH_CMPL_EVT (FM) 14 pbytes (hdl 151)
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): decodePendingEvent: Event ID: 4382
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): enqueuePendingEvent: event ID: 4, ATTACHING THREAD
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): enqueuePendingEvent: THREAD ATTACHED OK
I/com_broadcom_bt_service_fm_FmReceiverService.cpp( 578): [JNI] - TRANSMITTING EVENT UP : event = 4
V/FmReceiverEventLoop( 578): onRadioSearchCompleteEvent()
V/FmReceiverService( 578): onRadioSearchCompleteEvent()
D/FmReceiverService( 578): ******* ******* Processing job:FM_SEEK_STATION TimeSent:1:43:58 PM
D/FmReceiverService( 578): ***** ***** processCommands:[]
D/FmReceiverService( 578): []
D/FmReceiverService( 578): ****** ****** Adding FM Job: FM_SEEK_STATION TimeSent:not yet
D/FmReceiverService( 578): ***** ***** processCommands:[FM_SEEK_STATION TimeSent:not yet]
D/FmReceiverService( 578): ***** ***** processCommand:FM_SEEK_STATION TimeSent:1:43:59 PM
V/FmReceiverService( 578): seekStation():1
Part of the FM radio driver is also in /system/lib/android_runtime.so.
The upshot:
The FM Radio is heavily tied into the Desire's firmware (and I'll bet the same is true with the Droid Incredible as well); the FM apk itself is tied to Sense, so if the radio can be made to work, at least for the time being, it will be tied to Desire ROMs.

I would die if someone got a radio app working. The local rock station here in baltimore is fantastic and I throughly enjoy listening to them but I dont want to carry another device when I go to the gym or jogging. I'd gladly pay for a pro/donate version too...

So are we going to maybe see this on sense roms. Coming soon???
-------------------------------------
Sent via the XDA Tapatalk App

I have a theory I'd like to try which requires me to successfully boot a custom kernel, but my self-built kernels thus far have failed to boot :-/. If its just a matter of audio path, it should be easy to get this to work (I hope)

It's pity that there is no HTC insider to help us.. That would save so much PITA trying to figure out the HW from looking at the SW...
Anyway, several things:
1) The references are incorrect, should be QSD8250 and BCM4329.
2) I've looked up the Broadcom chip. No detailed pinouts and/or HDD/SWI, but a brief is available - and it says enough:
http://www.datasheetdir.com/BCM4329+download
First, FM radio doesn't have its own dedicated interface, it's encapsulated and passed over either WiFi or BT. Later in the spec it specifies BT interface, so that part is clear.
Second, it's also clear that the data coming from BT chip isn't coming analog - it's coming over high speed UART, the same one that's used to control BT. The same HW, but different usage.
So to capture the audio output of FM radio, one needs to look at the Desire source and find in its BT stack - or more probably outside of the stack - the procedures responsible for configuring high-speed UART, select those that reconfigure it for audio, and duplicate on Nexus. I don't know if any recoding takes place, but it should also be visible in the code. Looks like there can't be any HW problem that can prevent the radio, since HS-UART is already connected and functional in controlling BT, and we know for fact that I2C is connected, since Paul's builds control the radio.
I'd do that myself, but it'll take me ages to navigate in the code, not being familiar with it and not having enough SW background. I hope one of the devs can take the job. As it goes for HW, I can support the part that deals with QSD reconfiguration, if there will be any specific questions that I'll know the answers to.

Jack_R1 said:
It's pity that there is no HTC insider to help us.. That would save so much PITA trying to figure out the HW from looking at the SW...
Anyway, several things:
1) The references are incorrect, should be QSD8250 and BCM4329.
2) I've looked up the Broadcom chip. No detailed pinouts and/or HDD/SWI, but a brief is available - and it says enough:
http://www.datasheetdir.com/BCM4329+download
First, FM radio doesn't have its own dedicated interface, it's encapsulated and passed over either WiFi or BT. Later in the spec it specifies BT interface, so that part is clear.
Second, it's also clear that the data coming from BT chip isn't coming analog - it's coming over high speed UART, the same one that's used to control BT. The same HW, but different usage.
So to capture the audio output of FM radio, one needs to look at the Desire source and find in its BT stack - or more probably outside of the stack - the procedures responsible for configuring high-speed UART, select those that reconfigure it for audio, and duplicate on Nexus. I don't know if any recoding takes place, but it should also be visible in the code. Looks like there can't be any HW problem that can prevent the radio, since HS-UART is already connected and functional in controlling BT, and we know for fact that I2C is connected, since Paul's builds control the radio.
I'd do that myself, but it'll take me ages to navigate in the code, not being familiar with it and not having enough SW background. I hope one of the devs can take the job. As it goes for HW, I can support the part that deals with QSD reconfiguration, if there will be any specific questions that I'll know the answers to.
Click to expand...
Click to collapse
Bah, my brain was on neutral when I typed those numbers. At least this explains why HTC replaced the Bluetooth stack with something they cooked up, but it will be non-trivial to get FM radio into an AOSP. I think I know what has to change in the kernel to make this work though at this point.

Sonic McTails said:
Bah, my brain was on neutral when I typed those numbers. At least this explains why HTC replaced the Bluetooth stack with something they cooked up, but it will be non-trivial to get FM radio into an AOSP. I think I know what has to change in the kernel to make this work though at this point.
Click to expand...
Click to collapse
Go go go! I really want to have it enabled on my N1! Feels like without it, my N1 is lacking some piece of its soul.

Keep up the work guys.
No longer will our FM chips remain flaccid and unused. LOL.

If u need help building kernel or any other I am there to help.

charnsingh_online said:
If u need help building kernel or any other I am there to help.
Click to expand...
Click to collapse
Me two!

why don't we invite the great [ cyanogen ], he who has done some great stuff that hasn't been opened by Google .. I think we must request him and open a bounty for FM radio to get working on nexus one.

thalib_atc said:
why don't we invite the great [ cyanogen ], he who has done some great stuff that hasn't been opened by Google .. I think we must request him and open a bounty for FM radio to get working on nexus one.
Click to expand...
Click to collapse
-----------
great idean infact he might be comin up with some new rom already thats my assumption can be true u never knw

thalib_atc said:
why don't we invite the great [ cyanogen ], he who has done some great stuff that hasn't been opened by Google .. I think we must request him and open a bounty for FM radio to get working on nexus one.
Click to expand...
Click to collapse
I'd def donate to anyone that got the FM radio working..... I know many people would, I'm sure there are people working on it (if they believe its possible that is)..... Sure would be an awesome feature to add and would allow me to get my buddy to shut up about his incredible......

this is a useful dmesg (enabling FM Radio)
Code:
[ 705.437744] Enable FM HEADSET
[ 705.460845] Disable TTY
[ 705.471862] Audio: FM: start
[ 705.471984] q6fm_open()
[ 705.472106] Audio: _audio_rx_clk_enable: device 0x0107ac8a, group 0
[ 705.472320] Audio: _audio_rx_clk_enable: icodec_rx_clk_refcount = 1
[ 705.472595] Audio: _audio_rx_clk_enable: icodec_rx_clk enabled
[ 705.509124] acdb: 974 bytes for device 5, rate 48000.
device is controlled by btld through
/sys/class/htc_accessory/fm & /sys/class/htc_accessory/tty
desire source code:
arch/arm/mach-msm/htc_headset_common.c
arch/arm/mach-msm/qdsp6/audio_ctl.c
drivers/serial/msm_serial_hs_bcm.c

Kali- - it's great info. Thanks.

HTC Desire FM Radio App
Hi
In my case, i have an HTC Desire and i want to develop an application to delay the radio.
This is because in my country many people like to listen to the radio while watching football, but it is usually 2 o 3 second ahead of the image (since DVB)
I've decompilied the HTC Radio application with Dexeter, but it's a little bit complicated to understand (not impossible, but difficult).
For example, this is a piece of code from BroadcomFMTuner:
Code:
.method private setCmdStatus(I)V
.limit registers 5
; this: v3 (Lcom/htc/fm/BroadcomFMTuner;)
; parameter[0] : v4 (I)
.line 25
iget-object-quick v0,v3,[obj+0x8]
new-instance v1,java/lang/StringBuilder
invoke-direct {v1},java/lang/StringBuilder/<init> ; <init>()V
const-string v2,"setCmdStatus("
invoke-virtual-quick {v1,v2},vtable #0x3b
move-result-object v1
invoke-virtual-quick {v1,v4},vtable #0x36
move-result-object v1
const-string v2,")"
invoke-virtual-quick {v1,v2},vtable #0x3b
move-result-object v1
invoke-virtual-quick {v1},vtable #0x7
move-result-object v1
invoke-static {v0,v1},com/htc/fm/FMLog/d ; d(Ljava/lang/String;Ljava/lang/String;)V
There's a better way to decompile the application or is the source code available anywhere?
There's other similar code to access the fm chip or documentation i can look?
Thanks
Sergio

I know you can make it guys! Thanks for your hard work on this!
Grande Kali- ! Let's put some italian flavour on this ...

thalib_atc said:
why don't we invite the great [ cyanogen ], he who has done some great stuff that hasn't been opened by Google .. I think we must request him and open a bounty for FM radio to get working on nexus one.
Click to expand...
Click to collapse
I've poked around with it a bit but haven't really had any success.
CodeAurora has a bunch of code for FM radio- I don't know how much of it is applicable though. Most of it is framework/HAL stuff and geared towards a specific board.

I'll start working on it from tomorrow. Will see where I can get it too. I would need someone who already has worked on it to make stuff faster. Shoot me a pm anyone who has already worked on it

hey charnsingh... any news so far?

Related

Using Cell Tower Identifier for Location-Based Services?

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.

[DEV] Bluetooth Experience

Hi,
I managed to start bluetooth on nookie froyo, BT scan is working well(on command line), sometimes it shows devices in the android gui.
The steps : ( use at your own risk and only for comfirmed devs)
Add bluetooth capabilities (HCILL) in kernel
Toggle the WL12XX_RFKILL flag on in evt1a defconfig.
Take the bluetooth firmware (bts file) from gforge.ti ( wl1271 firmware) for froyo pandroid and put it into /system/lib/firmware, alias /lib/firmware to /system/lib/firmware (useful for command line).
boot the kernel
and then
echo 0 >/sys/class/rfkill/rfkill0/state
echo 1 >/sys/class/rfkill/rfkill0/state
hciattach -s 115200/dev/ttyS1 texas
hcitool scan must show you your BT devices (if discoverable)
Stability is not yet here, Maybe some problems with UART high speed handling ?
This is very positive, it seems that the wl1271 chip is well connected to omap3621...
I will continue to dig ...
Occip
You are my new hero! Good work man.
Sent from my NookColor using XDA app
So very cool....
Sent from my LogicPD Zoom2 using Tapatalk
outstanding!
Woah. You, sir, just won TWO free copies of the internets! Can't wait to see where this goes, now that the HW seems to be good!
Forgive my ignorance on the subject but what does this mean? maybe the remote possibility of finally being able to use skype and actually talk with a bluetooth earpiece/headset?
That means, IMHO:
1) The hardware is in fact connected. One less thing wait for the salting crew to find.
2) It is possible bluetooth can now be activated in software, since the devs now know it is not a complete waste of time trying to activate hardware that is present but not live.
3) This guy freakin' rocks!
Homer
/me breaks out bt gps dongle to charge it, and runs out to his car to see if the bin on his center dashboard can fit a 7" screen. Yep! Just fits.
forget skype, wiimote! YAY
deolarte said:
forget skype, wiimote! YAY
Click to expand...
Click to collapse
Forget skype?! Blasphemy!
I'm definitely looking forward to being able to use a BT mic + A2DP audio. Now that Clockwork recovery is mostly working, it's going to be great when a 2.2/2.3 custom ROM is out there to just flash and get all this stuff working and easily installed/reproducible.
jay084 said:
Forget skype?! Blasphemy!
Click to expand...
Click to collapse
Wiimote > Skype
This is wonderful. Now I can connect a wiimote to my nook to play emulators with!
Is this something that can be added to the stock firmware, or does it require compile options that aren't enabled in B&N's firmware?
SCORE!!!!
This means it is only a matter of time until our NCs are fully-enabled tablets. Awesome
Anyone know if Android's location services can use Bluetooth GPS as a "native" location device?
I have a hunch that B&N may officially add this in the 2.2 update to make it either look better in a marketing sense (why they would have it off I do not know except... * ) or to go with some fancy accessory.
*They might have it off due to a radio licencing fee they would have to pay or something... No firm data on this IMO just an observation.
Outstanding!
sent from my nookcolor using the xda app
starkruzr said:
SCORE!!!!
This means it is only a matter of time until our NCs are fully-enabled tablets. Awesome
Anyone know if Android's location services can use Bluetooth GPS as a "native" location device?
Click to expand...
Click to collapse
You might be able to tether your android phone's GPS to your NC using Bluetooth with an app in the market called BlueNMEA and an app called Bluetooth GPS in the market. Bluetooth GPS allows your android device to use an external Bluetooth NMEA compatible GPS with apps that require a GPS, like Google Maps. So if you put BlueNMEA on your phone and turned your phone into the antenna and then put Bluetooth GPS on your phone to receive the signal, it might work.
very good!!!
IM0001 said:
I have a hunch that B&N may officially add this in the 2.2 update to make it either look better in a marketing sense (why they would have it off I do not know except... * ) or to go with some fancy accessory.
*They might have it off due to a radio licencing fee they would have to pay or something... No firm data on this IMO just an observation.
Click to expand...
Click to collapse
They probably left it off because, right now, the Nook Color is not open to 3rd-party software. There's nothing available (officially) that can use it, so there's no reason to spend development resources getting it running.

chipset access or API for low level access

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.

MCU Source / Feature Request

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 ?

How to send/ write Canbus messages directly from HU

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.

Categories

Resources