hi,
i like to give a short update:
currently i am testing the processes of selecting a cell and the network. the processes depend on the coverage, the sim card (network, inserted or not) and the mode (manual or automatic network selection). i hope i will finish this week.
to configure mode and sim card and other parameters in the future, i use the VTY, you already know from the OpenBSC project. there you can get informations about the subscriber, the mobile station and the received cells (system informations).
i will move all hacked parameters (test sim) to VTY config file. manual network selection mode requires reaction of the user, so it will also be added to the VTY. later the VTY can also command the "call" part to dial, answer and hangup a call.
my idea: later these VTY command structure may be used for the phone's menu (up - down - enter - escape), if compiled appropiate. also: if layer 3 is running on the phone, the serial port could directly connect to the VTY, so the phone gets a console interface for debugging and faster configuration.
currently the process (with sim card) ends while trying to do a location update. if the given channel is not supported, the program exits. to prevent this, just keep radio TX feature disable. the cell will be re-selected again and again (hopefully if the process works correct).
sometimes, especially at the first run, the radio process stops. (no results for measurements, no sync to selected frequency.)
also there is something i am wondering: calibration especially for the burst signal phase is measured and then stored on the eeprom by the manufacturer. do we use it? or do we need to do our own calibration?
regards,
andreas
Hi Andreas,
On Wed, May 12, 2010 at 02:58:36PM +0200, Andreas.Eversberg wrote:
also there is something i am wondering: calibration especially for the burst signal phase is measured and then stored on the eeprom by the manufacturer. do we use it? or do we need to do our own calibration?
there is no eeprom, it is stored in the same nor flash as the software is.
we have not yet been able to clearly identify and decode the parameters that they store. Without knowing the exact parameters and their interpretation, it will not be possible to use them from our software.
compal/motorola doesn't seem to use the standard method of storing those parameters in the FFS (flash file system) at the end of the image, but rather somewhere else :/
So yes, at the moment we will either use default parameters or have to calibrate the phones individually.
Cheers from Iceland, Harald
Hi Andreas,
On Wed, May 12, 2010 at 02:58:36PM +0200, Andreas.Eversberg wrote:
my idea: later these VTY command structure may be used for the phone's menu (up - down - enter - escape), if compiled appropiate. also: if layer 3 is running on the phone, the serial port could directly connect to the VTY, so the phone gets a console interface for debugging and faster configuration.
I really like the idea, but I think we need to move to something much more flexible than the current VTY data structures to make that work. The existing VTY code is a pretty useful tool, but it has quite some limitations and shortcomings that cannot be fixed quickly. One of its uglinesses is how you specify the context sensitive help strings (as multi-line strings with \n in them, part of what you pass to DEFUN). Other aspects are that all new nodes need to be hacked into the VTY core and you cannot define them yourself (see the NS_NODE that I have just introduced 2 days ago).
Once those issues are resolved, the VTY code could become a standard feature of libosmocore, and we wouldn't need to hack that code while still implementing any command line menu structure we'd like.
baseband-devel@lists.osmocom.org
-
Andreas.Eversberg -
Harald Welte