FORUMS
Remove All Ads from XDA

chipset access or API for low level access

7 posts
Thanks Meter: 2
 
By TheKrigla, Junior Member on 28th September 2012, 02:38 PM
Post Reply Email Thread
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
 
 
28th September 2012, 11:06 PM |#2  
Senior Recognized Developer
Flag Gdańsk
Thanks Meter: 3,468
 
Donate to Me
More
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. :P
The Following 4 Users Say Thank You to Rebellos For This Useful Post: [ View ]
29th September 2012, 06:30 PM |#3  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,209
 
More
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...
The Following 4 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
30th September 2012, 11:35 AM |#4  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,209
 
More
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...
The Following 3 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
1st October 2012, 08:31 AM |#5  
OP Junior Member
Thanks Meter: 2
 
More
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/referen...e-summary.html and here is Signal strength class http://developer.android.com/referen...lStrength.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!)...
The Following 2 Users Say Thank You to TheKrigla For This Useful Post: [ View ] Gift TheKrigla Ad-Free
11th October 2012, 01:22 PM |#6  
OP Junior Member
Thanks Meter: 2
 
More
hi *,

What about Gobi platform and GOBI dev?

BR
10th November 2012, 12:18 AM |#7  
Junior Member
Thanks Meter: 9
 
More
Quote:
Originally Posted by TheKrigla

hi *,

What about Gobi platform and GOBI dev?

BR

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 ?
7th February 2013, 04:48 AM |#8  
enigma99a's Avatar
Member
Thanks Meter: 18
 
Donate to Me
More
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
7th February 2013, 12:36 PM |#9  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,209
 
More
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
The Following User Says Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
8th February 2013, 01:24 AM |#10  
enigma99a's Avatar
Member
Thanks Meter: 18
 
Donate to Me
More
Quote:
Originally Posted by E:V:A

You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!


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
6th March 2013, 04:49 AM |#11  
Junior Member
Thanks Meter: 1
 
More
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 ?



Quote:
Originally Posted by enigma99a

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

The Following User Says Thank You to mknair For This Useful Post: [ View ] Gift mknair Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes