Hey.
I am new to the mailing list.
I have a Sony Ericsson J100a phone (GSM-850 / GSM-1900)The problem is that
I can not make calls and send SMS.
I think the problem I have is with the configuration of the stage of Radio
the phone, it seems that the SIM card is properly read.
I leave it attached the console output of osmocom.
OsmocomBB# show subscriber
Mobile Subscriber of MS '1':
IMSI: 72231001*******
ICCID: 8954310111*********
Service Provider Name: Claro AR
SMS Service Center Address: +543200000001
Status: U1_UPDATED IMSI detached TSMI 0x65945b7c
LAI: MCC 722 MNC 310 LAC 0x0c29 (Argentina, CTI PCS S.A)
Key: sequence 1 ec 94 74 df fa 7c 69 fb
Registered PLMN: MCC 722 MNC 310 (Argentina, CTI PCS S.A)
Access barred cells: no
Access classes: C1
List of forbidden PLMNs:
MCC |MNC |cause
-------+-------+-------
722 |34 |#255 (Argentina, 34)
722 |07 |#255 (Argentina, 07)
155 |0xff4 |#255 (155, 0xff4)
OsmocomBB#
OsmocomBB# show ms
MS '1' is up, service is limited
IMEI: 010848*********
IMEISV: 010848**********
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=722 MNC=310 (Argentina, CTI PCS
S.A)
cell selection state: C1 normal cell selection
radio ressource layer state: idle
mobility management layer state: MM idle, PLMN search
OsmocomBB#
Are missing information, please let me know to attach.
Thank you very much.
Hi,List.
I am studying the TCH AMR codec;
I using the first 8 bits of any TCH frame block to decide whether it is a
speech frame or a signal;
Although it will contain some non-speech frame; but I think it can capture
all the speech frame and
the captured file can be decoded correctly. is that right?
Hello everybody
When launching a local BTS (like with openbts on usrp or similar), one
needs to feed the BTS with a precise clock or a reference clock,
depending on the hardware. This step is needed because phones need a
precise clock from the BTS, otherwise they don't camp. Is that
correct?
If yes, my question is: how can a phone determine that the clock given
by the network is precise enough? I'm a bit confused: how can the
phone say that's not good, if it doesn't have a precise clock itself?
I tried to search something on google but results got are completely
out of scope. Can someone share some link?
Thanks to all
Dario.
On the C123 the following pads are usable
TP27 -- DLPWR (download power on), connects to Iota:RPWON
TP14 -- RxD Modem
TP13 -- TxD Modem
TP9 -- CTS Modem
TP39 -- GND
can you give me a picture thanks
Hi Tobias!
Regarding the problem with your current German T-Mobile SIM and
OsmocomBB:
The 0x60 that was received at startup is actually a "waiting time
extension" byte. A quick read through the calypso SIM driver by dexter
reveals that procedure byte handling is not implemented completely (only
in the special case of RUN GSM ALGO).
So basically what happens is that the card sends 0x60 to let the reader
know that it is alive, but that it needs some more time to respond. The
next byte 0x9f was then the first half of the status word.
However, due to the incomplete SIM driver, the code thinks 0x60 0x9F is
the status word, which of course is unknown.
I'm not able to look into fixing this myself right now, but maybe
somebody on the list has an interest in looking into the bug.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Sylvain, hi list!
I'm experimenting with burst_ind and TCHs right now and ran
into some problem I couldn't solve yet.
After receiving an Assignment Command for a hopping TCH/F I
call l1ctl_tx_dm_est_req_h1() with all necessary parameters
and tch_mode GSM48_CMODE_SPEECH_V1 or _EFR.
After that I do get burst indications containing the received
bits on up- and downlink for the active arfcn on each
consecutive frame number.
BUT the rx level measurements are most of the time very low
and sporadic higher, surely not from that nearby bts and the
very close cellphone.
It looks like the layer1 doesn't "hit" the right timeslot
on the right arfcn at the right time.
There are some possible sources of error leading to that, like
hopping parameters, channel number and MA list.
But I checked these and I took all of them directly from the
ASS CMD, the MA as word list in ascending order, like in layer23
IMM ASS handling.
The specific AC doesn't have any specialties like Starting Time
or "before time" parameters.
So my question is if there is some obvious pitfall I'm missing
and are there any suggestions how to debug that?
Regards,
Mad