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 josephli,
> Read stored BA list mnc=01
the mobile application stores the last cells and neighbour cells (band
allocation) of each network. this way the scanning is much
faster when restarting. because you use the SIM card with MNC == 02 the
first time, there is no band allocation stored for that. the mobile will
do a full scan in this case.
> while the sim card service I am tesing is actually with mnc 00 and 02.
i know that MNC == 0 will not work until i commited improvements of cell
selection process last sunday. you should retry that, but first try with
an MNC > 0.
can you provide debug output when trying a call?
also can you provide VTY output of "show ms" before you make the call?
regards,
andreas
hi,
i just fixed some locking issues the last days. fix will follow. it took
a bit longer, because there were some race conditions. it took up to
about one hour until it crashed. my way to detect the area where the
crash happened, was to turn on buzzer before that area, and turn it off
after that area. after many hours of approximation, i finally found out
that the major crash happend during _talloc_zero. (first it looks for a
free memory chunk, then it allocates it.) since it can be called from
all contexts (main, irq, fiq), it need to be locked against any
interrupt, otherwise the memory chunk can be assigned multiple times.
(the process of _talloc_free is "atomic" and requires no locking.)
because it seems pretty stable, i think it is time to merge some
branches into the master. (i made a 6 hours call yesterday. and no crash
after bugfix ever since.) i will do that together with sylvain, if we
find the time this weekend.
currently i use the jolly/voice together with the sylvain/traffic
branch. i am able to use an isdn phone togehter with linux-call-router
and make/receive calls. audio is passed both ways. i think this is a
stage where it actually become "usable". (if not moving arround.)
one of my major work for the next weeks/months will be the neighbour
cell measurement, cell re-selection, and handover. this is essential
when moving with the phone.
regards,
andreas
Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
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
Hi,
I am trying to use burst_ind branch of osmocom. I have noticed that layer23 creates bursts****.dat files when it indicates uplink. What data are written to these files and what should I use to see its data? Thank you.
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
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)
Hello,
I have a ursp1 working fine and I want to use my c123 to conenct to it
with osmocombb.
Now I face some problems. First of all I have no sim, so I do:
sim testcard 1 001 01
The usrp runs a testnetwork (001 01)
I don't know how I can associate with the usrp. I tried:
network search (lot of output and also my testnet)
network show (nothing happens)
network select 1 001 01: Network not in list!
Any idea what I'm doing wrong? Would be really Cool if i could use
opensource only.
With best regards,
Paul
Hi All!
That's true, I managed to run U-Boot on MT6235, but linux kernel is
not fully functional yet (it's fresh stuff as I managed to ran it on
Tuesday and then I was off to conference).
For MT6235 development I chose Sciphone G2, which is pretty cheap.
After some time I managed to download code to SRAM (just 64KB) using
MTK's FlashTool.
MTK FlashTool communicates over UART directly with MT6235 bootloader
and sends its own chunk of code (about 58KB) which is executed in SRAM
and communicates with FlashTool.
I found on pudn.com some pack to customize code loaded by FlashTool,
thanks to which I could download my own code to SRAM (without JTAG).
The problem was that it had to be linked with some security libraries
which occupied about 56KB and not much memory left for my own code.
Then I decided to try find JTAG pins to get all control on MT6235.
That took me sometime, but finally I succeeded.
The other bigger issue was initializing DRAM controller to be able to
download bigger code (linux kernel + uboot) to external RAM. In
sciphone there is problem that all interesting chips are under metal
shield which is pretty havily soldered. In this case I couldn't read
what kind of RAM memory is mounted without destroying the board (I
don't have such soldering machine which could unsolder so big metal
shield). Thanks to JTAG I could attach to target and then dump DRAM
controller registers from processor running MTK's software, but
setting these values after processor start and configuration of PLL
didn't work.
I decided to disassemble bootloader which could show me how DRAM
controller is initialized and how code fron NAND is loaded (to be able
to flash U-Boot and kernel to NAND so MT6235 will start my code
automatically and I will not have to use JTAG). Currently I have
knowledge how internal MT6235 bootloader is loading code from memory
during startup and I also extracted procedure of DRAM controller
initialization. Thanks to that I'm able to run U-Boot from the very
begining of processor startup.
The problem is that I have just one piece of Sciphone G2 and I don't
want to flash it yet to not break existing code in it. Thanks to
running device I'm able to attach with JTAG and check how peripherals
are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm
not 100% sure if I will flash it back, phone will startup. That's why
I bought second piece of Sciphone G2 and should receive it today or on
Tuesday (this Monday is holiday in Poland). In this case I'll flash
U-Boot to NAND and try to make it working. Then we could load the rest
of code from U-Boot (to RAM or NAND over serial).
You can see how my setup looks on attached picture.
The good thing about it is that the same bootloader is used in MT622x,
so it should be fairly easy to do the same on phones based on that
SoCs (but unfortuantely it's just ARM7).
If it comes to code, of course I can share it on "git.osmocom.org".
Currently it's just basic port of U-Boot and not much for linux
kernel, but I'm working on this now so I'll push it when it'll be
ready.
Currently I'm working on driver for NAND memory for U-Boot, so we
could flash linux kernel. When that will be ready I'll push the code.
Then I'll switch to linux kernel and when it'll be functional I also
push the code. At this stage you will not need to have JTAG and you
could load the code over serial in U-Boot.
If it comes to GSM I didn't work with it before. I actualy worked 6
months in L2/3 team for LTE (on RRC) but it's different story.
That could be really outstanding thing if we could run first phone
ever with whole code open (from BB up to APP).
BR,
Marcin
Hi Dario,
i suggest you to download the last Sylvain's burst_ind, because is improved of some features and patch it manually with Nohl's patch.
Then you will be able to dump the bursts using ccch_scan, instead of layer23.
Cheers,
Luca
> Can someone drive me to the right direction?
P.S: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1754
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.
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
hi,
i just finished SMS support for osmocombb. everything is committed in my
jolly/testing branch.
in order to support SMS, i extracted the SMS transcoding from openbsc.
(jolly/sms branch) the SMC and SMR layer protocols are extracted and
rewritten and use messages between layers and have state machines. they
are added to libosmocore also. (jolly/sms branch) openbsc (jolly/sms
branch) now uses the SMS layers and transcoding of libosmocore.
LAPDm now supports correct handling of SAPI 3 datalink, especially on
SACCH. the mobility management and radio ressource layers of osmocombb
now support MM connections with SAPI 3.
i have tested it on test BTS setup only, so feel free to run it and
report bugs.
regards,
andreas
Hi guys,
I dunno if that is the right place for my concern about building the
osmocomBB source. Here is what I already have done:
- downloading the sources for osmocomBB and GNU toolchain for ARM,
- setting the PATH for the arm-elf-* executables,
- calling make in the src directory.
Now, this appears as response of the make command in the terminal:
cd shared/libosmocore/build-host && ../configure
configure: error: cannot find install-sh, install.sh, or shtool in ".."
"../.." "../../.."
make: *** [shared/libosmocore/build-host/Makefile] Error 1.
If you need details about my system, you can look at the following
snippet from the config.log file:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libosmocore configure UNKNOWN, which was
generated by GNU Autoconf 2.65. Invocation command line was
$ ../configure
## --------- ##
## Platform. ##
## --------- ##
hostname = ubuntu-stefan
uname -m = x86_64
uname -r = 2.6.32-24-generic
uname -s = Linux
uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2032: error: cannot find install-sh, install.sh, or shtool in
".." "../.." "../../..".
So, I would be very glad, if someone could give me a hint to solve the
problem. Thank you in advance.
Regards,
begy
hi,
i am thinking about moving sms code from openbsc to libsomocore.
my idea is to move the core code of openbsc to libosmocore's src/gsm and
include/osmocom/gsm/ respectively.
one problem is that the transaction structure of osmocombb and openbsc
is different. for sms support there could be a common part inside the
union of each transaction:
struct gsm_trans {
...
union {
...
struct {
uint8_t link_id; /* RSL Link ID to be
used for this trans */
int is_mt; /* is this a MO (0) or MT (1)
transfer */
enum gsm411_cp_state cp_state;
struct osmo_timer_list cp_timer;
enum gsm411_rp_state rp_state;
struct gsm_sms *sms;
} sms;
};
};
i would suggest to move the common part to libosmocore and name it
"gsm_trans_sms". then both openbsc and osmocombb can use the same sms
structure. also the "gsm_sms" structure itself must be generalized and
not rely on openbsc structures. (i have not yet looked at it.)
to get reference to the private gsm_trans, openbsc and osmocombb can now
use "container_of" in the specific sms glue code.
any ideas / suggestions?
andreas
Hi all:
I try make usrp work on Muti-antenna mode , 1 to downlink , 1 to uplink.
first , i only decode downlink, it can found FCCH,but can't decode sch.
any suggestion?
tianxing@tianxing-MS-7345:~/gsm/airprobe-gprs/gsm-receiver/src/python$ ./gsm_reive_usrp_mono.py -c 122
A side: Flex 900 Rx MIMO B
B side: Flex 900 Rx MIMO B
gain_a: 45.0
gain_b: 45.0
A side: The carrier frequency is set as 959400000.0
B side: The carrier frequency is set as 959400000.0
mux_val = 0x2301
input_rate: 571428.571429 sample rate: 0.527472527473 filter_cutoff: 145000.0 filter_t_width: 10000.0
>>> gr_fir_ccc: using SSE
input_rate: 571428.571429 sample rate: 0.527472527473 filter_cutoff: 145000.0 filter_t_width: 10000.0
>>> gr_fir_ccf: using SSE
Key: '0000000000000000'
Configuration: '0C'
Configuration TS: 0
configure_receiver
1319360150.211137 3014114160: fcch found on position: 24508
1319360150.211206 3014114160: freq_offset: -2659.853516
1319360150.254086 3014114160: fcch found on position: 77189
1319360150.254132 3014114160: freq_offset: -261.283386
sch.c:260 ERR: conv_decode 11
1319360150.307770 3014114160: fcch found on position: 135276
1319360150.307814 3014114160: freq_offset: -2574.190186
sch.c:260 ERR: conv_decode 10
1319360150.352075 3014114160: fcch found on position: 188023
1319360150.352120 3014114160: freq_offset: -375.097321
sch.c:260 ERR: conv_decode 8
Hi, all
The osmocomBB no AMR support yet now (only FR, HR and EFR).
/* no AMR yet */
void dsp_load_tch_param(struct gsm_time *next_time,
if (tch_mode) {
switch (l1s.tch_mode) {
case GSM48_CMODE_SPEECH_V1:
*tch_mode = *tch_f_hn ? TCH_FS_MODE : TCH_HS_MODE;
break;
case GSM48_CMODE_SPEECH_EFR:
*tch_mode = *tch_f_hn ? TCH_EFR_MODE : SIG_ONLY_MODE;
break;
default:
*tch_mode = SIG_ONLY_MODE;
}
}
i checked the product datasheet, the C123 can support AMR from the beginning.
does anyone can give me some information to patch it?
BTW, i havn't 30 source, so i can't reference it.
Best regards
Aegean Chou
First Osmocom GMR code release
As some of the readers may already know, a couple of Osmocom developers
have been working on a new sub-project: OsmocomGMR.
The primary goal of this project is to provide a reusable and clean
implementation of the various layers of GMR-1.
What is GMR-1 ? Well, it stands for "GEO Mobile Radio" and it's a set of
specifications describing a satellite based mobile phone network heavily
inspired from GSM. One of the major commercial operators of GMR-1
technology is "Thuraya", providing coverage over
Europe/Africa/Asia/Australia.
So far the implementation focused on the lowest layers:
* Physical layer with FCCH sync and demodulation support for
* pi4-CBPSK and pi4-CQPSK bursts.
* Channel coding layer (scrambling/puncturing/convolutional
coding/crc/interleaving/...)
And some ancillary tools to exploit those:
* A good capture tool to listen to particular ARFCN(s) and
channelize them properly
* Wireshark support (BCCH only so far)
The first 'demo application' using all of the above provides
functionalities similar to what airprobe is for GSM: An air interface
protocol analyzer that goes all the way from capturing data off-the-air
to sending packets to wireshark for analysis. Limited to BCCH only
currently but this will evolve with time.
Development was mainly done by Sylvain Munaut, with help from Dimitri
Stolnikov (early signal captures and his great capture tool), Harald
Welte (initiating the project) and Steve Margraf (testing different
setup and antenna ideas).
If you'd like to know more, you are encourated to read the wiki
(http://gmr.osmocom.org/) and join the mailing list
(http://lists.osmocom.org/mailman/listinfo/gmr)
--
- 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)
R M <rm.engineer84(a)gmail.com> wrote:
> I am looking for Vitelcom TSM30 source code. I tried searching for it
> in Google. I am not able to find it.
I have already helped the OP out off-list.
In case anyone else is looking for a copy of that code and all known
mirrors have been pulled: I have a copy in my possession, and I've
been meaning to put it up on my FTP server, i.e., a new public mirror
that would be completely shutdown-proof. (I don't use clouds, I run
everything on my own physical HW in my own physical control, housed in
my own personal datacenter on my own soil which I have declared to be
my own nation with my own laws, so no one in the world can make me
take anything down.) However, I am very very technologically-backwards,
and my current server HW/OS platform is too ancient to host a 500 MiB
blob. (The booty is in the form of an ISO image and appears to contain
a huge Windows-based development environment in addition to the actual
source.) For ages I've been meaning to set up an additional FTP
server on newer HW that can host such big stuff, but that progress is
very very slow-going for a bunch of personal reasons.
Because I consider it to be my fault that I still haven't followed
through with my ages-old promise of setting up that new FTP server, I
hereby attempt to make up for it somewhat by making the following
offer: if anyone would like a copy of that TSM30 source code, is not
able to find it anywhere else, and is not willing to wait however many
more months for me to set up that darned server, you can give me your
snail mail address and I'll send you a CD-R recorded from that 500 MiB
ISO image.
With the above out of the way, I happen to have some unanswered
questions about the TSM30 phone itself which I wonder if perhaps
someone in this community might have some answers to, so I've decided
to use this thread (started by someone else to whom I have no relation)
to try asking them. :-) (And yes, I've already tried Googling quite
extensively.) OK, here we go:
1. Would anyone happen to know the basic specs for the TSM30 phone
from an ordinary user's perspective? Which GSM bands does it
support? What kind of features does it offer? Judging from a
cursory bird's-eye-level look at the source code, it seems to be a
few notches above a basic primitive phone like Mot C123, but not
quite a smartphone either. I realize that one can probably extract
all the answers from the source if one were to study it for months
on end (I had no idea it would be this huge!), but I was wondering
if anyone already happened to know the answer.
Basically I'm trying to decide if it would be worth my while to try
to acquire an actual TSM30 hardware unit - which in itself seems to
be very non-trivial.
2. Has anyone been able to find a service manual and/or schematics for
this phone?
3. Does anyone know the hardware in the TSM30 compares against other
Calypso-based phones, such as Mot C123, Openmoko GTA02 or the
Leonardo reference design? What are the similarities and
differences?
TIA a lot for any clues,
MS
Hi,
I am looking for Vitelcom TSM30 source code. I tried searching for it
in Google. I am not able to find it.
The link that is provided in the wiki is dead.
Has any one else found it?
If yes can you please provide me the link also.
Regards
RM
only DSP patch is released which allow you to sniff one time slot out of 7.
rest code is not published and i guess will never be published
On Thu, Oct 6, 2011 at 3:30 PM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Sniff code.. as shown in c27 video (Marten Christophe)
>
>
> ---------- Forwarded message ----------
> From: Marten Christophe <technosabby(a)gmail.com>
> To: Sylvain Munaut <246tnt(a)gmail.com>
> Date: Thu, 6 Oct 2011 01:26:59 +0000
> Subject: Sniff code.. as shown in c27 video
>
> Hello Sylvain,
>
> If sniff code has been released as shown in the chao Video conference c27
> .. if any sniff code have been merged to any of Osmocom branch, lately i
> have lost the track of mails and git for quit a some time.
>
> Kind Regards,
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
--
Akib Sayyed
Matrix-Shell
akibsayyed(a)gmail.com
akibsayyed(a)matrixshell.com
Mob:- +91-966-514-2243
Hello Sylvain,
If sniff code has been released as shown in the chao Video conference c27 ..
if any sniff code have been merged to any of Osmocom branch, lately i have
lost the track of mails and git for quit a some time.
Kind Regards,
Hi guys..
I have a question about cipher mode.
I saw, that currently a5/1 and a5/2 is implemented.
Now, I want to force the phone to use no encryption (A5/0). Is it
enough to disable both of these algos?
Because when I tried that, I was not longer able to sign in..
Are there any patches that are necessary, or may it be, that the
network is not willing to provide a non-encrypted connection?
Usually, the phone is using A5/1 and with that algo, everything is
working fine..
Thanks for your help.
Ronny
