This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
rola roladunjoye at gmail.comHi 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-c-tp4004815.html Sent from the baseband-devel mailing list archive at Nabble.com.