Hi All,
Many of us are striving to find a way to make use of OBB but due to limited knowledge of programming we get stuck at one point or the other. I've tried to make OBB work for me but nothing has happened.
I've passed through the level of installation and file configuration with everything set except for an assuming bug left unfix in gsm322.c or prim_pm.c.
This bug is at the point of power measurement when cell selection is in the state of any cell. The first band is always measured accurately while the next band range works at layer1 with no response back to mobile. Due to this, the same second band range power is measured twice and that leads to overwriting error.
I've look through the code to figure out where it is appropriate to make correction in order for the process to flow accordingly. But, in as much as I try, I end back at the same spot of not knowing where to effect a change.
Two conspicuous identifiable issues are:
1. PCS arfcn range calculation seems to be incorrect. The initial arfcn and final are passed with extremely high range values in reverse order.
2. Perhaps as a result of the above, no response of measured power is feed back to mobile and that breakdown the program flow in gsm322.c. Thereby causing the same erring band to be measured twice and stuck in that cycle of measurement.
I just need a guidance on what changes to make in order to fix these issues.
I will greatly appreciate it if the only response is just to confirm if I'm right or wrong in my assumptions.
Thanks.
Sincerely,
Rasaki
-- View this message in context: http://baseband-devel.722152.n3.nabble.com/Unfix-BUG-in-GSM322-c-and-prim-pm... Sent from the baseband-devel mailing list archive at Nabble.com.
- PCS arfcn range calculation seems to be incorrect. The initial arfcn and
final are passed with extremely high range values in reverse order.
Are you sure the "high range" is not just caused by the ARFCN_PCS flags ? (which is 16384 IIRC)
Since DCS and PCS arfcn # overlap, PCS is treated specially and remapped with 16384 added to them.
Cheers,
Sylvain
Hi Sylvain,
I've been going through the code all the while and making sure that I set all the parameters as it should be before making any response to your reply. During this course I stumbled on the list modified file with changes made before 850 and 1900 bands could be supported by Osmocom-BB (http://bb.osmocom.org/trac/changeset/58ac7e0e98c448dcece8e7dfa53f484c982e96c...). I performed some tests and I have my observation below.
I tested with two different working registered SIMs from two different GSM carriers.One of the SIMs stuck in the processing of reading SIM information and the work with an hitch. My best guess reason for the first SIM stuck situation is the SIM reader inability to retrieve large number supported PLM list stored in the SIM. I presumed this by comparing the result of the same SIM file request number to the outcome of the second SIM.
The second SIM works perfectly, retrieved every SIM request information except for the previously stored scanned cell-info. Comparing the outcome of the SIM request file number to those posted by others on the mailing-list made me concluded that the unable information to be retrieved is the previously cell-scanned info.
Though this anomaly does not affect continuous functioning of the mobile application but it affects the power scan state. Ordinary power scanning of the cell could have been done initially with the stored cell-info in the SIM but that is not the case. Due to this the scan state starts with all available cells around. I performed all the above test using Pirelli-dpl10.
My question is could there be anything missing out in the process of adopting PCS1900. I ask this because when never I configure to use 850 band only, I do not not have any error except for the fact that the carriers only use 1900band in my area.
Secondly, could inability to retrieve stored cell-info be due to different in ARFCN. Because I have only seen people being successful with 850 band and not 1900. My test of 850 with Pirelli ended with scanning stage of fbsb without any info. I know that will not work because I've tried manually selecting 850 on my regular phone ending with no service. So my hunch is still that somewhere along the line ARFCN for PCS1900 got tangled.
Now my contentions are,
1. Inability to read previously stored cell-info. 2. Breakdown of power scan for ARFCN of PCS1900
I will be so grateful if these angles can be look into. Thank you.
Sincerely,
Rasak
-- View this message in context: http://baseband-devel.722152.n3.nabble.com/Unfix-BUG-in-GSM322-c-and-prim-pm... Sent from the baseband-devel mailing list archive at Nabble.com.
baseband-devel@lists.osmocom.org
-
rola -
Sylvain Munaut