Dear all, I vae the C115 with a T1 USB to Serial cable with the Prolific
chipset.
When i run osmocon i get :- an its just sits there with no further
processing.
./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/loader.compalram.bin
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=17120, hdr_len=4, dnload_len=17127
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=17120, hdr_len=4, dnload_len=17127
got 1 bytes from modem, data looks like: 00 .
got 2 bytes from modem, data looks like: 2f 00 /.
got 1 bytes from modem, data looks like: 1b .
got 3 bytes from modem, data looks like: f6 02 00 ...
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6c l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 00 .
I think the cable is ok as when i run my fingers on the tip i get random
Zeros so it appears to be talking to the cable.
Also when i tried to run Mobile i get the :- even though i created the
Mobile.cfg file in /etc/osmoco
Failed to parse the config file: '/home/raz/.osmocom/bb/mobile.cfg'
Please check or create config file using: 'touch
/home/raz/.osmocom/bb/mobile.cfg'
I have spent some hours researching the lists and trying various things to
no avail but I want to continue until I resolve this issues and use this
great stack to learn about the GSM network.
Please advise.
Great full for any help or pointers but this maybe a timing issue that is
difficult to debug.
Thanks
Raz
hi,
i did a lot of resarch and testing on cell selection and re-selection
process the last two week.
the cell selection process, network selection process (manual and
automatic) and mobility management process were already implemented in
OsmocomBB a long time, but turned out to be buggy and incomplete. i made
test drives to check the process and debugged it.
the re-selection process is new. it is used to track surrounding cells
while listening to the BCCH of the current cell (camping on a cell).
special extension to the layer1 firmare is used to measure neighbour
cells. if an neighbour cell becomes 'better', the mobile switches to
that cell, depening on different criteria. now it is possible to move
with OsmocomBB.
the re-selection process is not handover! handover is a process where a
phone switches between cells while doing a call. handover is one next
step to implement. the process is a little more complex, because it
requires not only neighbour cell measurements, but also syncing to them
without interrupting the traffic channel. most layer 3 stuff of handover
is already implemented.
if you like to play and test your moving OsmocomBB, you can check out
the "jolly/roaming" branch. it contains the extension to layer1, as well
as sim reader and fixes from "sylvain/testing" branch. use both "mobile"
and "layer1" firmware from this branch.
in order to see some process at VTY, you can do:
enable
monitor network 1 (continously display the strongest cell and neighbour
cells)
show ms 1 (to see current states)
show neighbour-cells 1 (to see a more detailed current list of
neighbours)
andreas
Hi,
in the osmocom bb mobile.cfg I don't see any posibility to set a fixed
Kc encryption key and the tmsi.
How could I achieve that osmocom uses my defined Kc and tmsi?
cheers,
Simian
So far three persons have indicated their interest to join
a meeting at my place.
Considering the time it takes to drive to my place, it
probably makes sense to have the meeting at the weekend
(either Saturday or Sunday) so that there is more time
for the meeting itself. I can suggest one of the following
dates for the first meeting, somewhere between 10:00 to
18:00 on each day:
25.8. (Sa) or 26.8. (Su)
1.9. (Sa) or 2.9. (Su)
8.9. (Sa) or 9.9. (Su)
So please let me know when you have time and also make
suggestions in which Osmocom topic you are interested
in so that we can have some sort of agenda for the
meeting to make best use of the time.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi josephli,
> Read stored BA list mnc=01
the mobile application stores the last cells and neighbour cells (band
allocation) of each network. this way the scanning is much
faster when restarting. because you use the SIM card with MNC == 02 the
first time, there is no band allocation stored for that. the mobile will
do a full scan in this case.
> while the sim card service I am tesing is actually with mnc 00 and 02.
i know that MNC == 0 will not work until i commited improvements of cell
selection process last sunday. you should retry that, but first try with
an MNC > 0.
can you provide debug output when trying a call?
also can you provide VTY output of "show ms" before you make the call?
regards,
andreas
hi,
i just fixed some locking issues the last days. fix will follow. it took
a bit longer, because there were some race conditions. it took up to
about one hour until it crashed. my way to detect the area where the
crash happened, was to turn on buzzer before that area, and turn it off
after that area. after many hours of approximation, i finally found out
that the major crash happend during _talloc_zero. (first it looks for a
free memory chunk, then it allocates it.) since it can be called from
all contexts (main, irq, fiq), it need to be locked against any
interrupt, otherwise the memory chunk can be assigned multiple times.
(the process of _talloc_free is "atomic" and requires no locking.)
because it seems pretty stable, i think it is time to merge some
branches into the master. (i made a 6 hours call yesterday. and no crash
after bugfix ever since.) i will do that together with sylvain, if we
find the time this weekend.
currently i use the jolly/voice together with the sylvain/traffic
branch. i am able to use an isdn phone togehter with linux-call-router
and make/receive calls. audio is passed both ways. i think this is a
stage where it actually become "usable". (if not moving arround.)
one of my major work for the next weeks/months will be the neighbour
cell measurement, cell re-selection, and handover. this is essential
when moving with the phone.
regards,
andreas
Hi ,List:
search some materials, find that the decode method of AFS convolutional
code is different from the EFS`, it use RSC, and need SOVA(soft output
viterbi algorithm). am i right?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/is-the-Viterbi-decode-for-the-AF…
Sent from the baseband-devel mailing list archive at Nabble.com.
I've pulled git repo today, but the RSSI firmware gets an error.
apps/rssi/main.c: In function `main':
apps/rssi/main.c:896: warning: 'a' might be used uninitialized in this
function
apps/rssi/main.c:896: warning: 'e' might be used uninitialized in this
function
CC board/compal_e88/rssi.compalram.manifest.o
LD board/compal_e88/rssi.compalram.elf
OBJ board/compal_e88/rssi.compalram.bin
CC board/compal_e88/rssi.highram.manifest.o
LD board/compal_e88/rssi.highram.elf
OBJ board/compal_e88/rssi.highram.bin
CC board/compal_e88/rssi.e88loader.manifest.o
LD board/compal_e88/rssi.e88loader.elf
OBJ board/compal_e88/rssi.e88loader.bin
CC board/compal_e88/rssi.e88flash.manifest.o
LD board/compal_e88/rssi.e88flash.elf
OBJ board/compal_e88/rssi.e88flash.bin
CC board/compal_e86/rssi.compalram.manifest.o
LD board/compal_e86/rssi.compalram.elf
arm-elf-ld: region LRAM is full (board/compal_e86/rssi.compalram.elf
section .data)
make[1]: *** [board/compal_e86/rssi.compalram.elf] Error 1
make[1]: Leaving directory src/target/firmware'
make: *** [firmware] Error 2
$ git pull
Already up-to-date.
$
Anyone experiencing the same issue?
