baseband-devel November 2011

baseband-devel@lists.osmocom.org

29 participants
40 discussions

burst_ind not working
by Dario Lombardo 11 Nov '11

11 Nov '11

Hi guys I'm not able to use cell_log under the burst_ind branch. I checkout the master, compile and run osmocon/cell_log. Everything works (I can see the cells). I checkout the branch, recompile, and run the same commands as before, but I get from layer1: [...] PM MEAS: ARFCN=71, 0 dBm at baseband, -138 dBm at RF DSP Error Status: 8 PM MEAS: ARFCN=72, 0 dBm at baseband, -138 dBm at RF DSP Error Status: 8 PM MEAS: ARFCN=73, 0 dBm at baseband, -138 dBm at RF [...] for every arfcn. Cell_log doesn't log anything: [...] <000e> cell_log.c:359 Measurement done <000e> cell_log.c:368 Measure from 0 to 124 <000e> cell_log.c:368 Measure from 512 to 885 <000e> cell_log.c:368 Measure from 955 to 1023 [...] I don't think it's a hardware problem, since it works with master. Am I missing something in the branch? Is anyone experiencing the same problem? Bye. Dario.

3 3

c1xx with filter re-work
by Lorik Sefaj 10 Nov '11

10 Nov '11

Hi all, Considering my soldering skills and the fact that I just ruined a c123 trying to replace the filters (which was working perfectly with patched burst_ind and got me a lot of downlink traffic to work with). Anyways without wasting your time my question is: does anybody have a c1xx with filter re-work for sale? I'd like to get some uplink traffic Thanks a lot and keep up the great work, J

3 5

Sony J120?
by Jay R. Worthington 08 Nov '11

08 Nov '11

Hi 'yall, before i break out the soldering iron, has someone already tried the J120? It seem's to be a tad newer version of the J100, but with an (FM-) Radio, the specs lists it as Calypso Chipset... Regards, Jay

1 0

calypso SIM driver on c139 (also: l1ctl SIM APDU)
by Gianni Tedesco 08 Nov '11

08 Nov '11

The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything. However, under simtest firmware no data is received by the phone, even the ATR is zero bytes... Anybody had this problem? Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P Gianni ----------------SIMTEST----8<----------------- Initializing driver: SIM: Registering interrupt handler for simcard-interface ====================== CALYPSO SIM REGISTER DUMP ===================== Reg_sim_cmd register (R/W) - FFFE:0000 |-REG_SIM_CMD = 0000 | |-REG_SIM_CMD_CMDCARDRST = 0 ==> SIM card reset sequence disabled. | |-REG_SIM_CMD_CMDIFRST = 0 | |-REG_SIM_CMD_CMDSTOP = 0 | |-REG_SIM_CMD_CMDSTART = 0 | |-REG_SIM_CMD_MODULE_CLK_EN = 0 ==> Clock of the module disabled. |-REG_SIM_STAT = 000b | |-REG_SIM_STAT_STATNOCARD = 1 ==> No card! | |-REG_SIM_STAT_STATTXPAR = 1 ==> Parity ok! | |-REG_SIM_STAT_STATFIFOFULL = 0 | |-REG_SIM_STAT_STATFIFOEMPTY = 1 ==> Fifo empty! |-REG_SIM_CONF1 = 000c | |-REG_SIM_CONF1_CONFCHKPAR = 0 ==> Parity check on reception disabled. | |-REG_SIM_CONF1_CONFCODCONV = 0 ==> Coding convention is direct (normal). | |-REG_SIM_CONF1_CONFTXRX = 1 ==> SIO line direction is in transmit mode. | |-REG_SIM_CONF1_CONFSCLKEN = 1 ==> SIM clock in normal mode. | |-REG_SIM_CONF1_reserved = 0 ==> ETU period is CONFETUPERIOD. | |-REG_SIM_CONF1_CONFSCLKDIV = 0 ==> SIM clock frequency is 13/4 Mhz. | |-REG_SIM_CONF1_CONFSCLKLEV = 0 ==> SIM clock idle level is low. | |-REG_SIM_CONF1_CONFETUPERIOD = 0 ==> ETU period is 372/8*1/Fsclk. | |-REG_SIM_CONF1_CONFBYPASS = 0 ==> Hardware timers and start and stop sequences are normal. | |-REG_SIM_CONF1_CONFSVCCLEV = 0 ==> SVCC Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFSRSTLEV = 0 ==> SRST Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFTRIG = 0x0 (FIFO trigger level) | |-REG_SIM_CONF1_CONFSIOLOW = 0 |-REG_SIM_CONF2 = 0940 | |-REG_SIM_CONF2_CONFTFSIM = 0x0 (time delay for filtering of SIM_CD) | |-REG_SIM_CONF2_CONFTDSIM = 0x4 (time delay for contact activation/deactivation) | |-REG_SIM_CONF2_CONFWAITI = 0x9 (CONFWAITI overflow wait time between two received chars) |-REG_SIM_IT = 0000 | |-REG_SIM_IT_SIM_NATR = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_WT = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_OV = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_TX = 0 ==> On write access to REG_SIM_DTX or on switching | | from transmit to receive mode (CONFTXRX bit) | |-REG_SIM_IT_SIM_RX = 0 ==> On read access to REG_SIM_DRX. |-REG_SIM_DRX = 0100 | |-REG_SIM_DRX_SIM_DRX = 0x0 (next data byte in FIFO available for reading) | |-REG_SIM_DRX_STATRXPAR = 1 ==> Parity Ok. |-REG_SIM_DTX = 00 (next data byte to be transmitted) |-REG_SIM_MASKIT = 003f | |-REG_SIM_MASKIT_MASK_SIM_NATR = 1 ==> No-answer-to-reset interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_WT = 1 ==> Character wait-time overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_OV = 1 ==> Receive overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_TX = 1 ==> Waiting characters to be transmit interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_RX = 1 ==> Waiting characters to be read interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_CD = 1 ==> SIM card insertion/extraction interrupt is masked. |-REG_SIM_IT_CD = fffe0010 |-REG_SIM_IT_CD_IT_CD = 0 ==> SIM card insertion/extraction interrupt is unmasked. Power up simcard: * Power enabled! * Clock enabled! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) Reset simcard: * Reset pulled down! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! SIM-T0: Transceiving APDU-Header: (a0 c0 00 00 0f) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 4: Input / No output (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Incorrect or missing answer -- aborting! e0 73 d7 b9 ae ea bf 7e f7 3b 7f 6f 32 fe 25 (15 bytes) Test Phase 1: Testing bare sim commands... * Testing SELECT: Selecting MF SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! ==> Status word: ffff * Testing SELECT: Selecting DF_GSM SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... At this point it hangs "forever" - well at least half hour.

7 11

GPRS decode tutorial
by Dario Lombardo 08 Nov '11

08 Nov '11

Hello everybody Not sure if someone has pointed it out already, but I'm getting stuck following the gprs decode tutorial [...] - Prepare OsmocomBB's burst_ind branch cd ~/gprs_sniffer/osmocom-bb git checkout origin/sylvain/burst_ind git checkout d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5 At this point I get fatal: reference is not a tree: d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5 Next step fails too... pretty obvious... # patch -p1 < ~/gprs_sniffer/gprs_multi.patch can't find file to patch at input line 5 [...] Can someone drive me to the right direction? Thanks! Dario

4 4

cp2102 (betemcu, B75937)
by lonelysurfer 08 Nov '11

08 Nov '11

...a never ending story: i have a working ftdi-ttl, but the cp2102-adapters (http://www.ebay.de/itm/USB-2-0-to-TTL-UART-6PIN-CP2102-Module-Serial-Conver…) with the same cable dont work under ubuntu or windows. if i rub the top of the 2.55mm with my finger random data appears. but the loader doesnt upload the firmware. i used the txd, rxd and gnd pins and checked the connections with a multimeter. i tested -m c123xor, -m c123 and the default firmware. flashing custom baudrates was no problem. drivers are installed correctly (stady ttyusb0 under ubuntu/ com1 under win). is there any hint? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489323p… Sent from the baseband-devel mailing list archive at Nabble.com.

1 0

Re: Pirelli never syncs
by Andres Berroa 07 Nov '11

07 Nov '11

I'm trying to sync to the 1800 or the 900 bands with the Pirelli, I'm not using 850/1900. I tried ccch_scan with different cells. I attached the logs. On Mon, Nov 7, 2011 at 11:48 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote: > > The only thing it's different from you it's > > I live in the Caribbean, but I have GSM networks on all four bands. > > And what band are you trying to sync to ? And with which hardware ? > > The ARFCN of PCS and DCS are overlapped and so I have no idea how > 'mobile' behaves in that case. > > You can try the ccch_scan binary with the -a option to force going to > a cell and just see if the bcch sync works at all. > (for PCS ARFCN you have to add 32768 to the arfcn number). > > Cheers, > > Sylvain >

1 0

Pirelli never syncs
by Andres Berroa 07 Nov '11

07 Nov '11

Hello everybody, I bought several Pirelli DP-L10. I checked out the master branch of Osmocom, changed the console.h and sercomm.h, and enabled the CONFIG_TX_ENABLE option. The code compiled successfully. I loaded the compiled firmware onto the Pirelli with osmocon, and after it loaded, I ran cell_log and mobile. But the phone never syncs to a cell. I first tried with the "no stick" option. But after this, I tried to find a strong cell (I used a Blackberry 9300 for this, it has a nice engineering screen). I found cells from -76 dbm to -104 dbm. I tried them all with the "stick xxx" option, but still, the phone does not sync to this cells. The last thing I tried was using the binaries a friend provided me. He compiled the code on his computer, he tested those binaries at his home, with his Pirelli, and it worked: he could sync. He sent me those same binaries, but still no luck, the phone cannot sync. I have tried this on 4 different computers, 2 different versions of Ubuntu, on Debian, and on a Mac. It doesn't seem it's an operating system problem, but I wanted to test it anyway. The only thing it's different from you it's I live in the Caribbean, but I have GSM networks on all four bands. Now, if I use my sim on the Pirelli, with the original firmware, it works. I can even make a call, so I think it's not a hardware problem. I tested with Nokia C118 on a 850Mhz network, but same story. I'm posting my mobile.cfg file, and some logs. Thank you for your help.

1 0

Re: delay in SIM reader interrupt handler
by Dieter Spaar 01 Nov '11

01 Nov '11

Hello Andreas, On Tue, 01 Nov 2011 12:28:05 +0100, "jolly" <andreas(a)eversberg.eu> wrote: > > i removed the delay, and it works. i checked the tsm30 source code. it > also sets the IO to input right after writing the last TX byte. (i guess > that the controller will trigger the IO switching at the end of > transmission.) so why do we need that delay? are there any problems? I can't tell you exactly what went wrong (it was months ago that I worked on this part). But most certainly one of my Test SIMs did not work without this delay. So I would suggest to leave a comment at this place in case problems with certain SIMs occur. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

delay in SIM reader interrupt handler
by jolly 01 Nov '11

01 Nov '11

hi dieter, i like to clean up and merge the sim reader code with master branch. while looking at the code i found a delay_ms(1) in interrupt handler: ------- /* Used by: calypso_sim_transmit() to transmit the data */ if(regVal & REG_SIM_IT_SIM_TX) { #if (SIM_DEBUG == 1) puts(" Waiting for transmit...\n"); #endif if(sim_tx_character_count >= sim_tx_character_length) { txDoneFlag = 1; } else { writew(*tx_buffer,REG_SIM_DTX); tx_buffer++; sim_tx_character_count++; #if 1 /* Dieter: set to 0 to get problems with some cards */ /* its essential to immediately switch to RX after TX is done */ if(sim_tx_character_count >= sim_tx_character_length) { /* TODO: set a proper delay here, 4 is to long if not debugging and no delay is too short */ delay_ms(1); /* Switch I/O direction to input */ writew(readw(REG_SIM_CONF1) & ~REG_SIM_CONF1_CONFTXRX, REG_SIM_CONF1); } #endif } } --------- i removed the delay, and it works. i checked the tsm30 source code. it also sets the IO to input right after writing the last TX byte. (i guess that the controller will trigger the IO switching at the end of transmission.) so why do we need that delay? are there any problems? regards, andreas

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel November 2011