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.
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.
Hi.
Attached are set of patches with small improvements to cell_log, si_dump and mcc/mnc
printers.
Please review and merge if code is ok.
--
best regards,
Max, http://fairwaves.ru
> > I'm writing some UI/firmware [...]
> That sounds neat... are you doing it in some visible git repository perchance?
I'm just hacking on layer1/main.c right now. Not even sure I would put in a repo since I want to implement some form of t-9 character and word fanciness. Maybe I could make that a module or think of an open-source/free paradigm for entering text w/ the keypad.
http://www.google.com/patents?id=PmgCAAAAEBAJ (T9)
http://www.google.com/patents/US3967273 (funny bell labs method using two key presses always)
(the list goes on and on I think...)
My thinking is that I might start with this hacked layer1 and gradually try to bring bits of mobile into the firmware/ui.
Also just wanting to fiddle around with how the phone will "feel" with a console interface. aka UI prototyping.
Cheers,
Craig
Was wondering if anyone has tried to use qemu to make a device emulator? I'm writing some UI/firmware and it seems like it might be a nice way to iterate on code.
Also was thinking I would need to rework keypad.c so that I can get key hold/repeat events since I want to know when a key is being held down at some fairly short interval. Any suggestions/previous work/cautions?
Thanks,
Craig
I was trying to load some apps to a Motorola C139 and found that after building osmocom-bb that there were no chainload image files built. Am I using the wrong branch somehow? Are the instructions out of date on this page:
http://bb.osmocom.org/trac/wiki/MotorolaC140
./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin ../../target/firmware/board/compal_e86/chainload.compalram.bin
The page mentions something about a magic value that must be placed into memory for the bootloader... could that be added to osmocon somehow so that specifying -m c140 takes care of it?
"After the download has completed, it expects the magic string "1003" (0x31 0x30 0x30 0x33) at the RAM address 0x803ce0"
Thanks,
Craig
Dear all,
I was wondering if uplink sniffing is enabled by default in latest firmware as file "osmocom-bb/src/target/firmware/layer1/prim_sniff.c" has been modified and does not hold "#if 0" bit at line 288 anymore.
Thanks,
George Andguladze
Peter Stuge <peter(a)stuge.se> wrote:
> > Actually my hope is to build a quad-band phone
> That would be neat too.
> [...]
> I was thinking about phone-as-BTS, but same principle, no
> (or just the appropriate) filters.
Unfortunately these two goals (quad-band support on the one hand, and
filter hackability on the other hand) seem to be in conflict. It
seems to me that trying to build a quad-band phone using separate
antenna switch and Rx SAW filter components would be very messy,
probably too messy for an RF-clean PCB layout - hence necessitating
the use of an integrated RF front-end part that has all that mess
hidden inside. (See ftp.ifctf.org/pub/GSM/Calypso/M034F.pdf for an
example of wha I mean.)
But using an integrated RF FEM like that M034F would surely preclude
the possibility of filter hacking...
Once again, my goal is to produce a Totally Free Phone for everyday
use in one's pocket/purse, not GSM hacking - and I reason I must not
be the only person on this list who desires such; I reason that there
must be other lurkers on this list who watch with frustration as the
years go by, there are all kinds of hacks made, but virtually zero
progress toward an end-user-usable Free phone.
It's obvious that OsmocomBB and FreeCalypso will always be two separate
projects: the former focused on GSM hacking and security research, the
latter on everyday-phone end-user needs. All I'm hoping for is that
the two projects could be at least somewhat amicable, and cooperate in
things like amassing hardware knowledge - rather than be all-out
hostile.
SF
Sylvain Munaut <246tnt(a)gmail.com> wrote:
> And why exactly should we help you when you publicly stated [1] that
> you'd rather shoot us then yourself
> [1] http://lists.openmoko.org/pipermail/community/2012-March/066565.html
A little clarification is in order:
* In my past negative interactions with certain individuals who have
previously served as employees or contractors of Openmoko-Inc and
who currently serve as lead developers of OsmocomBB, the crux of the
dispute was those individuals' unwillingness to share with all
Humanity (yes, *all Humanity*, *not* "me" - I could be dead tomorrow
and nothing will change) those COFF object files with symbolic
information which Om-Inc had received from TI, and/or their voluntary
choice to live and/or accept voluntary citizenship in a country that
deems such sharing to be illegal - obviously a voluntary choice which
I have NOT made.
* There has been one major change in the year and a half since that
post of mine quoted by Sylvain - I have discovered this:
http://scottn.us/downloads/peek/
[In case ScottN, whoever he is, takes the ware down from his website,
it's already archived on my mini-Wikileaks at
ftp.ifctf.org/pub/GSM/LoCosto - but for as long as ScottN's copy is
up, it should be much faster.]
The discovery of the above source (which is almost complete source
with very little in object-only form) makes it now unnecessary for me
to sacrifice my life in a gunfire exchange with German or Russian
police in order to free Openmoko's COFF objects - I'm pretty confident
in my ability to recreate something very similar, but full-source from
this recently discovered "peek" ware and other more recently discovered
leaks, also on my FTP site.
> than help us in any way ...
It is true that I have chosen to use a different Free Software GSM
stack (plus UI etc) implementation for my personal use, hence any
contributions from me to the software side of the OsmocomBB project
are indeed unlikely.
However, I am hoping that the project to build new free phone hardware
can be done as a joint project between the two camps. The hardware
design files will be free for anyone to download and do with as s/he
pleases, and obviously each user is free to run whatever software s/he
likes: OsmocomBB, FreeCalypso, or some 3rd or 4th or other choice that
may exist in the future.
SF
Hello fellow Calypso phone hackers,
Not having found an already-existing Calypso phone that is exactly to
my liking (of the ones supported by OsmocomBB, the Pirelli comes
closest to my ideal, but even that one has a few things I don't like,
and most important of all, the availability of these phones on the
market has already shrunk down to zilch - so the day is near when it
will be just as legendary-unobtainium as the TSM30), I am setting out
to build my own.
I am setting out to design and build a new Calypso/Iota/Rita phone,
one that will be specifically designed to run Free Software as its
firmware: either OsmocomBB or FreeCalypso (my own personal alternative
free GSM firmware implementation), up to each user's individual choice.
My design will be a phone, not a modem (i.e., complete with the
essential UI elements, as in LCD and keypad), and it will be a
dumb/plain/feature phone, i.e., the Calypso will be the main/sole CPU -
not a smartphone like Openmoko etc.
Before I tackle the difficult problem of either making a new plastic
case or choosing some existing one, I will start out by building a
bare GSM development board - basically a complete phone sans case,
built on a non-form-factor-controlled PCB. This development board
will probably end up being very similar to the one which Harard Welte
has announced here a little over a year ago, but with one major
difference: *all* hardware design source files (as in schematic, BOM
and PCB layout source) will be openly released, with absolutely nothing
withheld, and in fact the development itself will take place in a
public source control repository. Therefore, regardless of whether I
succeed or fail in the ultimate goal of producing a complete phone
packaged in a plastic case, there will be an Open Source Hardware
design for a working Calypso GSM board which others will be able to
use as a starting point - something that wouldn't be possible (or at
least less convenient) with Harald's PDF-schematics-only version.
However, the above vaporware announcement is not the real purpose of
my post. Instead, I am currently in the negotiations with several
Chinese sellers of Calypso/Iota/Rita/etc chips, and I'm soliciting
advice on exactly which variant of each chip I should use:
* The Calypso chip in both GTA02 and Pirelli DP-L10 (the two existing
designs I use as references to be copied whenever it makes sense) is
PD751992AZHH. I can easily get this exact part, but I can also get
ones with GHH or AGHH suffixes. I'm venturing a guess in that the A
seems to go with the 751992 number, i.e., it's part of the die
revision, and as to the difference between GHH and ZHH, I'm guessing
that it's the RoHS difference: I'm guessing that GHH has balls made
of real SnPb solder, whereas ZHH has the "lead-free solder" junk
substituted instead. Because I'm very fortunate to NOT live in the
EU or anywhere near, I'm not subject to any EU-nian laws like the
RoHS idiocy, and I generally prefer to use real SnPb solder whenever
possible. So I wonder: can someone confirm if indeed PD751992AGHH
is the exact same Calypso chip as the PD751992AZHH used in the GTA02
and Pirelli phones, but with real non-RoHS solder balls instead, or
is it something different?
* Which Iota variant is better: TWL3014 or TWL3025? I'm thinking
TWL3025, reasoning that it being newer probably means having some
internal bugfixes or minor improvements, but perhaps the older
TWL3014 is better instead?
* As to the Rita, the base part number appears to be TRF6151C in all
phones currently supported by OsmocomBB, so I'm sticking with this
base part number. But there are additional suffixes after the 'C'
in that P/N - would anyone happen to know what these suffixes mean,
and which variant I should use?
* For the RF PA, I see that the GTA02 uses RF3166 from RF Micro
Devices (one of Harald Welte's posts regarding his planned Calypso
board also mentioned him planning to use the same PA), whereas the
Pirelli and most other feature phones supported by OsmocomBB tend to
use Skyworks parts instead. Which is better? I'm currently leaning
toward the RF3166, but if someone has a recommendation that is
actually backed by some knowledge/reason rather than just a guess
like mine, I'll listen. :-)
* If I do go with the RF3166, any idea as to what the different suffix
versions are?
TIA for any input,
SF
Peter Stuge <peter(a)stuge.se> wrote:
> It would be neat if you choose a filter part with a footprint that
> can also accomodate a balun more easily than in the Compal phones,
Actually my hope is to build a quad-band phone (unlike the dual- or
tri-band ones we have so far) by copying this reference design from
TI:
ftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf
[The above PDF came from one of the Chinese sites; the /pub/GSM
directory of my FTP site above is my own sort of mini-Wikileaks for
all things dealing with the Calypso and related things - I encourage
everyone to check out the collection of goodies which I've accumulated
so far, and which only keeps growing. :-)]
As you can see on that schematic, instead of using separate antenna
switch and Rx SAW filter parts, the Leonardo reference boards used
integrated RF front-end modules - in the case of the quad-band
Leonardo Plus, it's a quad-band RF FEM that works perfectly with the
Rita.
The specific part on that Leonardo+ board seems to be Epcos M034F. A
quick search for that part hasn't shown up any availability, but then
it was only a very quick search, and even if that specific part isn't
available, I reason that there must be functional equivalents from
other manufacturers.
> so that a phone could be assembled "either way".
You mean a filterless sniffer version? I have to admit that sniffing
and other GSM hacking aren't really my areas of interest - instead all
I want is a 100% "normal" cellphone, but with just one difference:
running software/firmware whose full source is physically available
(be it legal or otherwise) for the exercise of the Four Freedoms
defined by the FSF, as a moral requirement.
SF
hello, when reading gsm spec online i have understood that on an MT call the
BTS pages the phone on the RR paging channel(PCH) the phone then asks for a
channel in the RR channel request (RACH) the BTS replies with RR immediate
assignment(AGCH) etc etc
Now I have tried to see a live example of this using osmocom-bb
layer1/mobile + gsmtap/wirehshark
However I cannot figure out or see anywhere in these logs the *RR channel
request (RACH) packet*. Does GSMTAP or OsmocomBB actually capture the RR
channel request or am I missing something here??
the logs I get are like this
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) System Information Type 1
(CCCH) (RR) System Information Type 2
(CCCH) (RR) System Information Type 3
(CCCH) (SS)
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Paging Request Type 1
(CCCH) (RR) Immediate Assignment
and so on
Thanks!
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Channel-Request-Info-RACH-GSMTAP…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi
I am a beginner with RTL and observing that the baseband
spectrum is centred at 0 Hz and is asymmetric going from -1 MHz to +1 MHz. How
does one filter a part of such a spectrum? For example if signal of interest lied
in -300 kHz to -150 kHz. The filtering techniques for typical band pass
filters work with positive frequencies and have symmetric frequency selection
response. As such a 150 to 300 KHz band pass filter will select signal in both
150 to 300 kHz band as well as from -150 to 300 kHz. Is there a special
filtering method available to work with negative frequencies and with an asymmetric
baseband spectrum. I am sure this has been addressed as preassumably the FM and other signals of interest are filtered somehow. Anu indications will be appreciated.
Hello,
I am trying to run osmocom on Motorola C117.
Using the following :
PC(Ubuntu12 64bit)<---->USB To Serial cable (5v)<---->serial to
(3.3V)<---->phone
when i press power button all i can get is "fmtoolerror" . and there is no
more messages only that .
I am wounding if that means the phone is not working properly or it could
be a cable issue ?
Thanks very much .
