Hey there, I bumped into this error when testing gprsdecode from srldabs.de When I try the sample .dat files provided from srlabs.de it works fine though. Any hints?
Kind Regards
George AndguladzeSenior Software EngineerBusiness Management Technology
www.bmt.ge
Hey, I finally watched Nico's talk "let me answer that for you" and heard him say he ported layer2/3 to target.
Also found a mailing list message about him cleaning it up and putting it up on git and sending it to a few folks.
Did that code ever get shared? Would be cool to play around with and is certainly something I would eventually want to accomplish for my project of making a phone that works by itself.
-Craig
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
Hi all,
*I connected, sent and made call successful with osmocombb (with real IMSI
and IMEI).
But, now, I get error, always be rejected:*
OsmocomBB# show ms
MS '1' is up, service is limited
IMEI: 357337016773249
IMEISV: 3573370167732490
IMEI generation: fixed
automatic network selection state: A0 null
cell selection state: PLMN search
radio ressource layer state: idle
mobility management layer state: MM idle, PLMN search
OsmocomBB#
% (MS 1)
% Trying to registering with network...
*in my config file (/root/.osmocom/bb/mobile.cfg)**:*
!
! OsmocomBB () configuration saved from vty
!!
!
line vty
no login
!
gps device /dev/ttyACM0
gps baudrate default
no gps enable
!
no hide-default
!
ms 1
layer2-socket /tmp/osmocom_l2
sap-socket /tmp/osmocom_sap
sim reader
network-selection-mode auto
imei 357337016773249 0
imei-fixed
emergency-imsi 452040399998391
sms-service-center +84980200030
no call-waiting
no auto-answer
no force-rekey
no clip
no clir
tx-power auto
no simulated-delay
no stick
location-updating
neighbour-measurement
codec full-speed prefer
codec half-speed
no abbrev
support
sms
a5/1
a5/2
p-gsm
e-gsm
r-gsm
gsm-850
dcs
pcs
class-900 4
class-850 4
class-dcs 1
class-pcs 1
channel-capability sdcch+tchf+tchh
full-speech-v1
full-speech-v2
half-speech-v1
min-rxlev -106
dsc-max 90
no skip-max-per-band
exit
test-sim
imsi 001010000000000
ki xor 00 00 00 00 00 00 00 00 00 00 00 00
no barred-access
no rplmn
hplmn-search foreign-country
exit
no shutdown
exit
!
Anyone help me???, thanks a lot!
--
Thanks and Best Regards
--
From: Hoàng Mạnh Hùng
Hi,
I'm trying to run the latest osmocom-bb git on a Motorola C118 phone.
After a minor problem with the build (as you may've noticed in the
patch I've sent). I got to the point of successfuly running layer1 on
the phone and the mobile app on the PC (I have also enabled TX). The
process seems to be stuck on trying to perform a location update. The
status of the ms is always either:
show ms
MS '1' is up, MM connection active
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: connected mode 1
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: connection pending
mobility management layer state: wait for RR connection (location updating)
OsmocomBB>
or
show ms
MS '1' is up, service is limited (pending)
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: C3 camped normally
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: idle
mobility management layer state: MM idle, attempting to update
OsmocomBB>
I think, that because of this I can't make any calls or send sms (all
the requests are being rejected):
OsmocomBB# call 1 <X>
call 1 <X>
OsmocomBB#
% (MS 1)
% Call has been rejected
The log information from mobile when it's trying to do a location
update is show below:
<000b> gsm48_rr.c:2174 PAGING REQUEST 1
<000b> gsm48_rr.c:2141 IMSI 260021964220249 (not for us)
<000b> gsm48_rr.c:2132 TMSI fd82a501 (not for us)
<000e> gsm48_mm.c:344 Location update retry
<0005> gsm48_mm.c:345 timer T3211 (loc. upd. retry delay) has fired
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_TIMEOUT_T3211' event
in state MM IDLE, attempting to update
<000e> gsm48_mm.c:2199 Perform location update (MCC 104, MNC 002 LAC 0xb00f)
<0005> gsm48_mm.c:2333 LOCATION UPDATING REQUEST
<0005> gsm48_mm.c:2355 using LAI (mcc 104 mnc 002 lac 0xb00f)
<0005> gsm48_mm.c:2363 using TMSI 0x28a3d62e
<0005> gsm48_mm.c:914 new state MM IDLE, attempting to update -> wait
for RR connection (location updating)
<0001> gsm48_rr.c:5428 (ms 1) Message 'RR_EST_REQ' received in state
idle (sapi 0)
<000e> gsm48_rr.c:1318 Establish radio link due to mobility management request
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell
selection in state 'C3 camped normally'
<0003> gsm322.c:823 new state 'C3 camped normally' -> 'connected mode 1'
<0003> gsm322.c:3653 Going to camping (normal) ARFCN 19.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0001> gsm48_rr.c:366 new state idle -> connection pending
<0001> gsm48_rr.c:1465 CHANNEL REQUEST: 00 (Location Update with NECI)
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
<0003> gsm48_rr.c:4816 Channel provides data.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 5)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 0 ra 0x0e)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 4)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x07)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 3)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0f)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 2)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x01)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 1)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0a)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 1 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 0)
<0001> gsm48_rr.c:1605 Done with sending RANDOM ACCESS bursts
<0001> gsm48_rr.c:836 starting T3126 with 5.000 seconds
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x0a chan_nr 0x41 ARFCN 19 TS 1
SS 0 TSC 1)
<0001> gsm48_rr.c:2393 request 0a matches but not frame number
(IMM.ASS fn=22,6,30 != RACH fn=22,5,25)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-77 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 3 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:765 timer T3126 has fired
<000e> gsm48_rr.c:770 Requesting channel failed
<0001> gsm48_rr.c:366 new state connection pending -> idle
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection
in state 'connected mode 1'
<0003> gsm322.c:3565 Selecting ARFCN 19. after LOC.UPD.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:823 new state 'connected mode 1' -> 'C3 camped normally'
<0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state
wait for RR connection (location updating) (sapi 0)
<0005> gsm48_mm.c:2732 RR link released after loc. upd.
<000e> gsm48_mm.c:2676 Location update failed
<000e> gsm48_mm.c:2686 Try location update later
<0005> gsm48_mm.c:2688 Loc. upd. failed, retry #0
<0005> gsm48_mm.c:413 starting T3211 (loc. upd. retry delay) with 15.0 seconds
<0005> gsm48_mm.c:1143 We are camping normally as returning to MM IDLE
<0005> gsm48_mm.c:1159 Loc. upd. allowed.
<0005> gsm48_mm.c:919 new state wait for RR connection (location
updating) -> MM IDLE, location updating needed
<0005> gsm48_mm.c:909 new MM IDLE state location updating needed ->
attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event
in state MM IDLE, attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
Can you provide me any hints on how to debug this ? Why is the
location update failing constantly ?
Thanks in advance for your help.
Best regards,
Maciej Grela
Hi All
Just wanted to confirm that I got Osmocom-BB up and running on a Raspberry Pi.
I did not use the GPIO UART pins but USB <-> serial converters.
I tried Motorola C118 and C155 with success.
Everything you need is already described:
http://bb.osmocom.org/trac/wiki/GnuArmToolchainhttp://bb.osmocom.org/trac/wiki/libosmocorehttp://bb.osmocom.org/trac/wiki/Software/GettingStarted?redirectedfrom=Gett…
My previous problem seems to have been a not fully compatible crosscompiled toolchain. (it worked mostly, but I could not log-in to a cell and the spectrum view crashed on the RSSI Firmware.
Also if you want transmit capability (or flashing) then you need to activate those features in the makefile.
Thanks Sylvain (confirming c118 will work) and all others who are involved!!
PS: Any news on the "emulated BTS" that has been presented at last years chaos communication congress?
I have 2 C118s + 1 normal USB serial dongle + 1 capable of burst ind.
I hope this will suffice to also run also a possible future 1 trasmit phone + 1 receive phone configuration.
I assume that even without the filter change it should be enough to send a few meters of distance.
I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.
Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?
This is my first attempt to flash the loader.
1) The instructions on http://bb.osmocom.org/trac/wiki/flashing require
loading the file named "target/firmware/board/compal_e88/loader.*e88loader*
.bin".
Strangely I do not have this file after compilation. I have
loader.compalram.bin and loader.highram.bin. I also
have layer1.e88loader.bin and rssi.e88loader.bin.
Can you please guide me?
2) The guide for flashing an application says to use rssi.e88flash.bin.
Does that mean if I want to flash "layer1" as my application, then I must
use layer1.*e88flash*.bin at that point?
Thank you for your help.
B.
Akib Sayyed <akibsayyed(a)gmail.com> wrote:
> I was checking code given by you and tsm30 phone. header files are same.
Well, they aren't exactly the same, just very similar-looking. I have
not yet studied the diffs in detail. Yet is the operative word in the
previous sentence: as I've said before, my goal is to produce a code
version that works exactly like this Sotovik semi-src works on my Neo
Freerunner, but have it also work on my Pirelli DP-L10, and replace the
binary-only libs with reconstructed source pieces so I can make changes
like porting to the Pirelli and build with gcc.
When it comes to Layer1, in order to de-blob that part of our Leonardo
semi-src, I will need to lift L1 C files from either the TSM30 source
or the LoCosto one (probably some pieces from each), and then massage
them until they compile into code that matches what's in the current
binary objects. At that point I will need to become an expert on the
differences in the L1 code/headers between the different (semi-)source
leaks we are working with - but I am not at that point yet, I am still
working on reintegrating the lower layers of TI's software stack like
the BSP (aka "drivers", not DSP) initialization and the serial trace
mechanism.
> I just need to know what dsp patch needed.
Well, see, I don't know the answer to that question myself yet! But
your osmocon/layer1 output is telling me that the Calypso Lite chip in
your Compal phone has the same DSP ROM version (i.e., version 36) as
the 751992A in the Openmoko and the Pirelli, so whatever works for me
in that department should work for you as well.
In fact, I find it strange that any patches are needed at all for DSP
ROM version 36. The description of various DSP versions in TI's XML
configuration voodoo file g23m/system/busyb/unbusy_configset.xml
(inside the semi-src from Sotovik) reads:
<propertySet name="DSP" description="DSP code selection" shortName="SYS">
<valueDef value="1" valname="_fr" description="GSM 1.0: Full Rate" />
<valueDef value="2" valname="_fh" description="GSM 1.0: Full and Half Rate" />
<valueDef value="3" valname="_fe" description="GSM 1.0: Full and Enhanced Full Rate" />
<valueDef value="4" valname="_ac" description="GSM 1.0: All 3 Vocoder and Echo Cancellation" />
<valueDef value="6" valname="_al" description="GSM 1.0: All 3 Vocoder" />
<valueDef value="7" valname="_ad" description="GSM 1.0: All 3 Vocoder + Fax and Data" />
<valueDef value="9" valname="_2d" description="GSM 1.0: Full and Enhanced Full Rate plus Fax and Data" />
<valueDef value="16" valname="_16" description="GSM 1.5: All 3 Vocoder + Fax and Data - Vega+Omega - Ulysse rev B" />
<valueDef value="17" valname="_17" description="GSM 1.5: All 3 Vocoder + Fax and Data - Vega+Omega - Ulysse rev A" />
<valueDef value="30" valname="_30" description="GSM 1.5: All 3 Vocoder + CHED GPRS + Scheduler GPRS" />
<valueDef value="31" valname="_31" description="FIXME:???" />
<valueDef value="32" valname="_32" description="FIXME:???" />
<valueDef value="33" valname="_33" description="GPRS 1.5: All 3 Vocoder + CHED GPRS + Scheduler GPRS - Calypso" />
<valueDef value="34" valname="_34" description="GPRS 1.5: All 3 Vocoder + AMR + CHED GPRS + Scheduler GPRS - Calypso C035" />
<valueDef value="35" valname="_35" description="FIXME:???" />
<valueDef value="36" valname="_36" description="FR/HR/EFR/AMR, AEC, GPRS, SAM/CAL/CAL+ , OMEGA/IOTA/SYREN, Rework DSP34 (AMR, MELODY E2)" />
</propertySet>
So we see that GPRS first appeared in DSP version 30 (on some unknown
DBB chip before Calypso - maybe Samson?), then the early Calypso C05
chips had 33 in them (that's what the TSM30 apparently used - a very
early Calypso C05 rev A chip), then early Calypso C035 chips came out
with DSP version 34. The comments in l1_confg.h describe DSP 34 as
the first version with AMR. There are no informative comments for DSP
version 35, but I'm guessing that it was probably the version released
with the first Calypso+ chips.
But then look at the description for DSP version 36 quoted above: it
is explicitly described as supporting AMR in addition to the "regular"
voice codecs, 3 different DBB chips (Samson, Calypso and Calypso+),
and 3 different ABB chips: Omega, Iota and Syren. So I'm guessing
that the later fab runs of both Calypso C035 (what we have in our
current OsmocomBB-supported phones) and Calypso+ (that's the one with
the evil "secure" bootloader) were made with DSP code 36 instead of
34 or 35. And this DSP version 36 is described as a "rework" of DSP
34, whatever that means, with AMR and Melody E2 being mentioned
explicitly. Does "rework" mean bugfixes?
Thus it sounds from the description that DSP 36 is supposed to have
all of the bugs already fixed in it so that AMR ought to work out of
the box. Yet the TCS211/Leonardo code we've got from Sotovik does
apply a whole bunch of patches to the DSP code, and these patches are
definitely made specifically against DSP ROM code 36. And your
observation on your C118 that the DSP sends out good uplink when
configured for AMR, but puts out garbage on the voice downlink path
also suggests that our DSP ROM 36 still has buggy AMR support in it.
We will most likely find the correct answer when my FreeCalypso
project advances to the point where I have a de-blobbed version of
this newly found TCS211 code running on my Openmoko and Pirelli
phones. Hopefully this de-blobbed version that applies all of the
same DSP patches as the original will have AMR that "just works" - in
that case we can then disable the patches one by one until we find the
critical one whose presence or absence differentiates between AMR
working or not.
If you don't want to wait for me to get to that point, feel free to
beat me to it. You can buy a Neo Freerunner from www.pulster.eu if
you don't have one already, then flash my leo2moko port into it, and
confirm that AMR works. Then you can try disabling some or all of the
DSP patches (you should be able to do that with some minor surgery on
the existing blobs, without going through the slow and painstaking
de-blobbing/reconstruction process I'm doing for FreeCalypso) and
thereby find out which DSP patch (if any) is required for AMR to work
properly.
Or you could try extracting all of the DSP patches from this TCS211
semi-src (see my first reply to you in this thread for the links to
the extracted objects and the needed GNU Binutils patch), have your
experimental OsmocomBB/AMR code apply all of them in the same order as
the semi-closed firmware does (again, do a bit of disassembly with
objdump to find what this correct order is), and see if the
application of all of these patches makes AMR work for you.
VLR,
SF
Akib Sayyed <akibsayyed(a)gmail.com> wrote:
> Harald and Dieter Spaar
You should consider the possibility of accepting help from more than
just them...
> my question is does tsm30 support AMR operation
Do you have an actual physical TSM30 phone? If you do, you must be
the luckiest person on Earth, as these phones must be worth way more
than their weight in gold. If you don't have an actual TSM30, why
does it matter whether it supports AMR or not?
IOW, it seems to me that you are posing the question the wrong way:
rather than ask whether TSM30 supported AMR or not, you should be
asking how to get AMR support working on your current phone, which I
presume is one of the models supported by OsmocomBB, all of which use
a much newer Calypso+ABB+RF chipset than what the TSM30 had in it.
So, if you want to get help from those people who actually *are*
willing to help you (such as me), please answer the following two
questions:
1. Which phone are you using for your OsmocomBB/AMR experiments?
2. Please show us the console output you get from osmocon/layer1; I
want to see the "DSP API Version:" line in particular, which should be
printed twice.
My hypothesis is that getting AMR to work probably requires applying
at least one patch to the DSP code (others here have posted the same),
but before we can proceed further down that road, we need to know
which phone you are using and which DSP ROM version it has - hence my
two questions above; please answer them.
VLR,
SF
Akib Sayyed <akibsayyed(a)gmail.com> wrote:
> I am using TSM30 code for reference.
I assume you meant "I am using the TSM30 source as a reference for
what the ARM part of the Calypso should do" - which still doesn't
answer my question as to what you are doing as far as code running in
the Calypso DSP.
The TSM30 source targets a very old version of the Calypso chip (C05
rev A) that has DSP code version 33 in its ROM. The PD751992A version
of the Calypso that appears in the phones supported by OsmocomBB (at
least in the Openmoko and Pirelli ones, dunno about Compal as I don't
have any of the latter) seems to have DSP code version 36 in its ROM;
I say so based on this line in the osmocon/layer1 console output from
my Pirelli DP-L10:
DSP API Version: 0x3606 0x0000
The version of Layer1 code included in the TSM30 source contains
support for DSP versions up to 35, but not 36. Supposedly versions 34
and 35 (original Calypso C035 and Calypso+, respectively) can do AMR,
although probably with some patches required, but DSP 33 can't do AMR
at all, from what I understand. So it appears to me that the TSM30
source as a whole does not support the AMR codec (at least for calls;
there seems to be some support for AMR voice memos implemented in the
TSM30's separate TMS320DA250 processor), hence whatever AMR support
may be present in various individual components (bits of code which
Purple Labs got from TI) is likely to be incomplete or buggy or not
properly integrated etc.
FWIW, the TSM30 source includes DSP patches that are meant to be
applied atop DSP ROM versions 33, 34 and 35. But I doubt that any of
these patch versions would apply atop DSP ROM 36 in a working manner.
But the new Sotovik firmware semi-src (see my previous post) does
target the right version of the Calypso/Iota/Rita chipset (same as in
my Pirelli DP-L10 and Openmoko GTA02), and it is built for DSP version
36 - so it makes a much better reference version than TSM30. And it
does contain DSP patch files with "36_10" in the filenames. It is
unfortunate that this properly-matching version is not full-src like
TSM30, but only a semi-src, i.e., many of the important modules are in
object form only. But they are linkable/relocatable objects with full
symbolic info, so examining them with objdump (again, see my previous
post for the Binutils patch to support TI's variant of COFF) yields
quite a bit of useful insight.
This Sotovik firmware compiles into a functioning image, and with a
little bit of work I was able to get it to run on my Om GTA02:
http://lists.openmoko.org/pipermail/community/2013-October/069010.html
I was able to get this fw to work on the GTA02 keeping all of the
object blobs as they are because the GTA02 happens to use the same
TSPACT signal arrangement for its tri-band RFFE as the Russian cell
modem for which we got the fw semi-src, which is in turn based on TI's
Leonardo+ quad-band reference design with minimal changes. My next
step is to get this code to run on my Pirelli DP-L10 - it's also
tri-band, but the TSPACT signal arrangement is gratuitously different.
Thus before I can get the code to run on my Pirelli, I need to replace
the object blobs with something that I can compile conditionally for
CONFIG_TARGET_GTAMODEM vs. CONFIG_TARGET_PIRELLI. I am working on
that in my FreeCalypso project, but I'm currently pretty far from
approaching L1 - still working on the lower BSP layers.
If you want to get to the bottom of the AMR support mystery, my
recommendation would be to start with this known-working version which
targets our hardware (either do it on an Openmoko phone, or wait for
me to de-blob the code to make it work on the Pirelli too, or beat me
to it) - I am reasonably sure that this version has working AMR - and
then experiment from there. It appears that the code as it stands
(i.e., the current set of object blobs) applies a whole bunch of
different patches to the DSP code. You could try omitting these
patches and testing if AMR still works or if it breaks. (Or perhaps
some other things will stop working without the patches - you'll get
to find out!) If AMR works with the original full set of patches but
doesn't work when no patches are applied, you can then bisect to
determine which of the several patches is the critical one...
VLR,
SF
Akib Sayyed <akibsayyed(a)gmail.com> wrote:
> I am trying to implement AMR codec for osmocom-bb.
Doesn't AMR support require applying some DSP code patches?
Locating the DSP patch bits within a binary fw image read out of C1xx
or whatever would probably be an incredible pain, but you can use this
source/object mixed version instead:
ftp://ftp.ifctf.org/pub/GSM/TI_src/Sotovik/
If you download ti-libs-extract.tar.bz2 from the above, you'll find
all DSP patches in various *.obj modules in the l1_ext subdirectory
inside that tarball. The names of the little individual object modules
in that bunch are quite descriptive. The object format is TI's variant
of COFF; you will need this patch to GNU Binutils in order to grok
these objects:
ftp://ftp.ifctf.org/pub/embedded/ti-arm/
Enjoy!
Viva la Revolucion,
SF
Hello folks
I am trying to implement AMR codec for osmocom-bb. I got assignment commend
which is same as
T_AMR_CONFIGURATION amr_param;
amr_param.noise_suppression_bit=0;
amr_param.initial_codec_mode_indicator=1;
amr_param.initial_codec_mode=0;
amr_param.active_codec_set=0x95;
amr_param.threshold[0]=0x0a;
amr_param.threshold[1]=0x10;
amr_param.threshold[2]=0x18;
amr_param.threshold[3]=0x24;------------just random value
amr_param.hysteresis[0]=0x04;
amr_param.hysteresis[1]=0x04;
amr_param.hysteresis[2]=0x04;
amr_param.hysteresis[3]=0x04;----------just copied value from rest
config for hysteresis
l1ddsp_load_amr_param( amr_param);
Now when i make a call I here gliches or random noise. also after some
time there is radio signal loss and call is dropped.
I am not getting why this is happening.
--
Akib Sayyed
Matrix-Shell
akibsayyed(a)gmail.com
akibsayyed(a)matrixshell.com
Mob:- +91-966-514-2243
Hi,
I am trying to modify osmocomBB to work without the phone as layer 1.
My goal is that application will using socket to communicate with BTS
(modified BTS which can send and receive message throught sockets).
I analyzed the osmocomBB code and I found that I'll have to modify
osmocon.c (host/osmocon/osmocon.c) file. This file is interface between
serial communication and layer2. If I am right, I have to do this changes:
1. Delete functions handle the serial interface
2. Add new tool server to dnload structure
3. Creating new tool server for L1 interface (UNIX socket or IP socket
with GSMTAP)
4. Add callback function for reading from layer2 socket and forward
this messages to L1 socket interface.
Simplified I have to listen and forward packets from BTS to layer2
socket and from L2 to L1.
Do I think in right direction or I am wrong and it will need more
modifications?
Best regards,
Miroslav Babjak
Hi, all.
I am a newer to the osmocomBB project. And i was trying to load the firmware
to my C118 phone using CP210X converter. But after i input the command
below:
/.*/osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/PHONE_TYPE/FIRMWARE.compalram.bin*/
i can only get some reponse shown in the terminal like this:
got 1 bytes from modem, data looks like: 40 @
got 1 bytes from modem, data looks like: f8 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: e0 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 20
got 1 bytes from modem, data looks like: 00 .
It was pretty different from the instruction in the osmocomBB website as i
did not get the below messages:
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=13404, hdr_len=4, dnload_len=13411
so, i was confused if i have something wrong? can anyone help me with this?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/I-have-a-problem-when-load-the-f…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi All,
Please forgive me for the off-topic post. My cell service is so bad at
the house I can't hold it in any longer.
Does anyone have a recommendation for a repeater of the Sprint
network? I'd like a low power omni for the house, and a directional
back to the tower. (Or some step-by-step instructions for building
one?)
I'm less interested in a Femtocell because I have about an acre of
land, and I'd like to get some coverage in the back yard too.
For completeness, I have an iPhone and EVO 4G. So I would like 800
ESMR, 1900 PCS, and 2500 WiMax, if possible.
Thanks in advance and sorry about wandering a bit.
As I wrote here two months ago, I am seeking to build my own totally
free, end-user-usable Calypso-based quad-band GSM plain phone, as well
as possibly a Calypso-based free GSM modem module for smartphone
projects done by others, such as this:
http://talk.maemo.org/showthread.php?p=1376708
I already have the Calypso etc chips in qty 100 sitting in my desk
drawer - buying them on the Chinese surplus market turned out to be
surprisingly easy, and they most definitely have quite a bit more of
them available than the 100 I have bought.
Making my GSM device(s) quad-band as in 850/900/1800/1900 MHz is an
important part of my goal - contrast with the current OsmocomBB-
supported devices, which are only dual-band or tri-band at best. My
belief in the idea that our familiar Calypso/Iota/Rita chipset is
capable of supporting the quad-band configuration stems from the
existence of this TI reference design:
ftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_RD122.pdfftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdfftp://ftp.ifctf.org/pub/GSM/Calypso/M034F.pdf
The first PDF is something I just found on 52rd.com 2 days ago: it has
the Leonardo+ quad-band schematics plus a component placement drawing.
The 2nd PDF is the schematic which we have had for 2y now (might be a
very slightly different version, haven't visually diffed the two
closely enough) and the last PDF is for the quad-band RF FEM they used,
all from 52rd.com.
What I am still missing is a copy of the PCB layout (in whatever format
TI used for their reference designs all those years ago) corresponding
to those schematics. I have not yet found that article in my trawls
through 52rd.com - that's a search for a needle in a giant haystack.
(We also have a Leonardo_rev05.dsn file, in the same directory as the
ones listed above, but I assume it's the EDA source file for the
schematic capture phase only, no layout.)
I have already found a layout for a dual-band phone on an 8-layer PCB:
ftp://ftp.ifctf.org/pub/GSM/PCB/unknown-phone-pcb1.zip
and I can probably find a layout for a tri-band phone on an 8-layer
PCB too, something like Pirelli DP-L10. In contrast, Leonardo+ is a
very elegant quad-band design, and this TI doc says it's only a
6-layer PCB:
ftp://ftp.ifctf.org/pub/GSM/Calypso/chipsets+refdesigns.pdf
(see page 10)
We also have this:
http://scottn.us/downloads/peek/HW%20doc/I-Sample%20ref.%20design/Full%20pa…
I-sample is TI's LoCosto board, and it is quad-band. But LoCosto's
built-in RF block has separate LNA inputs for 850 and 900 MHz unlike
Rita, and I-sample uses a weird arrangement: the PA and the antenna
switch are integrated into one, but the Rx SAW filters are discrete.
So it isn't the same as Leonardo+.
Thus I am putting out this loud call for anyone who may have found a
copy of the Leonardo+ PCB layout somewhere on 52rd.com or some other
site of a similar nature. If you have a copy of this PCB layout or
know of a place where it can be downloaded, please speak up!
By helping me obtain a copy of that PCB layout, you would be helping
not only me, but also all those end users who would appreciate having
a quad-band GSM plain phone (or a modem for Neo900 etc) that is fully
documented and capable of running 100% free baseband firmware.
TIA,
SF
Hi list,
Sometimes when I run ./mobile -i 127.0.0.1, after output as below
-------excerpt----------------
<000b> gsm48_rr.c:2174 PAGING REQUEST 1
<000b> gsm48_rr.c:2132 TMSI ***** (not for us)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 30/16615m ra 0x7f chan_nr 0x0e MAIO 0 HSN 38 TS 6 SS 0 TSC 4)
<0001> gsm48_rr.c:2478 Not for us, no request.
<000b> gsm48_rr.c:2174 PAGING REQUEST 1
-----execerpt-end----------------------------------
I then want to launch ccch_scan,
after calling the function l1ctl_tx_fbsb_req,with the from mobile obtained parameters, similar to what Bhaskar did here:
http://lists.osmocom.org/pipermail/baseband-devel/2013-February/003799.html
But how and from where did Bhaskar call l1ctl_tx_fbsb_req function? Via netcat or socat to the osmocom-socket?
Regards erich
Hello,
I have problems flashing applications to the motorola c123. I tried it with several phones. Booting and running applications via USB is working well, but unfortunately flashing does not work. Following both of the tutorials (flashing and flashing_new) the command "host/osmocon/osmoload fprogram 0 0x010000 compal_loader.bin" outputs:
Loading 8192 bytes of memory at 0x10000 in chip 0 from file compal_loader.bin
bad crc 9bf1 (not e0bc) at offset 0x00000000
status 5242976, aborting
The memdump-command seems to work - I get a file compal_loader.bin with an md5sum of f59dee5a67b4114251acd0d279eacd85. The "funlock" and "erase"-command seemed to be successful, according to the output of osmocom ("Unlocking block at 0x00010000, meaning 00010000", "Erasing block 0x00010000...done") and the fact, that the original firmware does not load anymore, when erased :-)
I am using debian 6.0 (32bit) with a cross-compile-environment setup as described on http://bb.osmocom.org/trac/wiki/GnuArmToolchain to compile osmocom. The libosmocore has Patch 5b6416a729b46aab8ac7ea25a7ec91f3afeaf4fc (latest master-Branch), but I am using commit f2ab5e14967426f4845b51def4d9105af22f9ad2 from the master-branch of osmocom, because with the latest version of osmocom, the phones would not boot - I get only an output of "got 2 bytes from modem, data looks like: 04 81 ..", then osmocom exits.
The motorola c123 is connected via USB-Hub and an CP2102-Cable I got from sysmocom.
Could anybody please give me a where the error is or what else I can try to solve the problem. Thanks for help.
greetings,
Andreas