04-13-2009 10:17 PM
My application needs to query the MCC & MNC and with the help of this thread I found that the BB misinterprets the MCC (and the MNC?) code as a hex number and thus RadioInfo.getMCC returns the wrong number. For example I'm in Hungary and the MCC should be 216, but the device says it's 534, which is 0x216. This is clearly bogus as the ITU documentation does not mention that these should be interpreted as hex numbers (and well, decimal is the default). Also the ITU MCC document lists the number of free codes in each segment (like 100-199, etc) and from that it's evident that these are decimal numbers.
However the documentation does not mention this. It does talk about converting the MCC and MNC and combining then into a single hex number as the network id, but that's a different thing.
Now the really ugly and surprising part is that the device simiulator behaves differently... It doesn't seem to do this trick and the above API returns the same number I enter into the Simulate/NetworkProperties dialog. (I entered the MNC and MCC of my carrier and the simulator now shows the name of it on the screen. When I log the MCC seen by the application as a decimal number then it shows the same value that I entered into the Network Properties dialog...)
Can anyone confirm that it's the case with all device and OS versions above 4.2.0? Or was it fixed in some release and that's why I see the simulator and the device behaving in a different way? (Both are running 4.5, but the simulator is probably a later release.)
04-23-2009 11:39 AM
Please see the following (refer to the notes at the bottom for hex verus decimal information).
How To - Determine the MCC and MNC of the current network
Article Number: DB-00688
04-29-2009 09:42 PM
Thanks for your reply, but I've seen that document and coded around the issue before I posted here. It was meant to be something like a bug report. The problem with these KB articles is that by the time one finds it he has already invested quite some time into investigating the issue at hand. This, for one, should have been included in the official SDK JavaDoc, especiallysince the implementation is bogus. The MNC and MCC is not meant to be interpreted as a hex number. It's decimal, just have a look at the wikipedia article referenced from the KB article, or the ITU document referenced in the wikipedia article. They never state that MCC/MNC is hex, which means by default that it's decimal. More, if you go through the ITU list (as far as I can remember there was a PDF linked from the wikipedia article) all MCCs 'look like' decimal numbers, menaing that there isn't a single one having digits other than 0-9. Also the documents lists the number of free codes in each segment (each hundred when interpreting the numbers as decimal) and it's in line with the assumption that it's decimal.
Now I don't think that RIM can correct a bug that has been there for ages and that a lot of software rely on but they should at least depricate these buggy methods, add new ones returning the right numbers and documenting this in the javadoc.
04-29-2009 09:54 PM
Actually I couldn't rest I looked up the ITU document (ITU E.212 ) and it's pretty explicit about the MCC and MNC being decimal numbers (emphasis from me):
This Recommendation defines the following terms.
home network: The network of the service provider to which a given subscriber is
International Mobile Subscriber Identity (IMSI): The IMSI is a string of decimal digits,
up to a maximum of 15 digits, that identifies a unique mobile terminal or mobile subscriber
internationally. The IMSI consists of three fields: the MCC, the MNC, and the MSIN.
Mobile Country Code (MCC): The MCC is the first field of the IMSI and is three digits in
length. An MCC either identifies a country or a group of Networks that share an MCC for
Mobile Network Code (MNC): The MNC is the second field of the IMSI and is two to
three digits in length. The MNC, in combination with the MCC, uniquely identifies the home
network of the mobile terminal or mobile user.
07-22-2009 10:55 PM - edited 07-23-2009 03:25 AM
What I don't understand is why this is not indicated in the api.
Another thing I don't quite understand is that in the article you posted (How To - Determine the MCC and MNC of the current network) it says the corresponding hexadecimal value returned by getMCC() or getMNC() may contain the letter F as padding. So is the following code correct?
String s = Integer.toHexString(RadioInfo.getMNC(RadioInfo.get
int MNC = Integer.parseInt(s.replace('F', '0'));
// This is wrong: int MNC = Integer.parseInt(s.replace('F', '0'), 16);
Is it possible that it may also contain the letter 'f'?
Thanks for your help.
07-23-2009 04:02 AM - edited 07-23-2009 04:04 AM
Also what I have experienced is that GPRSInfo.getCellInfo().getCellId() returns the correct Cell ID if RadioInfo.getNetworkType() is RadioInfo.NETWORK_GPRS. However if I set the phone to use UMTS (3G), i.e. when RadioInfo.getNetworkType() is RadioInfo.NETWORK_UMTS the returned Cell ID is different from the value returned by any other phone I am using at the same location with the same SIM card. E.g. my BlackBerry 9000 returns Cell ID 46632 however the other (non-BlackBerry) phones return 26326568.
Is there any conversion needed for the Cell ID when using UMTS?
11-03-2009 01:05 PM
Is there a way I could get an answer to this post: here.
Are there any other useful forums where I could try?
In my opinion it's rather a serious bug, unless somebody proves me wrong. UMTS Cell IDs are just returned wrong by the API. I haven't experienced this bug on any other platform.
01-20-2010 07:06 PM
The blackberry methods getMCC and getMNC are returning binary codeded decimals.
The hex conversion trick just happens to convert these to decimal.
01-20-2010 07:16 PM
Well, yes, you can call misinterpreting a decimal number as a hex one as BCD, as it's essentially the same thing. But according to the documentation linked by Mark above, they are indeed hex numbers (i.e. the RIM developers thought those were hex numbers and didn't intentionally use BCD).