Hello! I Need Help
I install these three programs OpenBTS, OsmocomBB, Asterisk
Then run them, Everything works well
OpenBTS sent an SMS to my phones
I answered and he checked me
I registered into OpenBTS a second phone
I tried to transfer SMS between phones - all good
but when I try to call from one to another I did not get
Asterisk writes
================================================================
*CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for
seqno 179 (Critical Response) -- See
wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
================================================================
Why?
What do I do?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402…
Sent from the baseband-devel mailing list archive at Nabble.com.
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.
Anyone else experienced this with latest libosmocore from git?
./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test
stderr:
MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
All NS-VCs for NSEI 2901 are either dead or blocked!
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:229
/home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25:
8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_
bssgp_test
--
best regards,
Max, http://fairwaves.co
Hello
Biggest thanks for the osmocombb project!
I am trying to follow this wikki http://bb.osmocom.org/trac/wiki/flashing_new to flash rssi app
And facing this error
host/osmocon/osmoload fprogram 0 0x010000 compal_loader.bin
Loading 8192 bytes of memory at 0x10000 in chip 0 from file compal_loader.bin
bad crc 9bf1 (not 4190) at offset 0x00000000
status 69206016, aborting
How to solve it?
I use latest jolly/menu git branch
HW: C115 and c113 ( e88) both providing same error
--
Sincerely, Alexander.
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 working on bringing up nuttx on the c139. I am running this as I described previously by jumping from 0x2000 to 0x10000 with a small firmware image there and then nuttx is configured to run from flash at 0x10000. I configured nuttx RAM to live at 0x800100 to skip the exception vectors area that the compal loader sets up.
NuttX is coming up somewhat but getting stuck on an unregistered interrupt #21 which seems strange since there are 21 interrupts and I thought they might be 0-based so not sure what's going on here. Was wondering if there was some state that the compal loader setup that is giving me problems or if there is some other issue going on. If anyone has an idea off-hand let me know.
If I take a DEBUGASSERT() out is when I get the info about irq 21. With the DEBUGASSERT() in it seems I'm trying to do initialization during interrupt handling somehow? "This API should not be called from interrupt handlers" is the comment near the assert in sem_wait().
Attached is a serial log from the phone booting up. I've added a lot of debug logging beyond what is normally in NuttX. I included first a log with DEBUGASSERT() included and then one without.
Thanks,Craig
Here is a patch for a simple "jumper" app which loads at 0x2000 and which disables the irqs (thought it might help with the nuttx startup error I have) and jumps to 0x10000 (where I have flashed nuttx).
I'm submitting a patch to nuttx as well for building nuttx.bin for running in compal_e86 flash.
I may have fouled up the patch due to being on jolly/menu. Wasn't sure if you wanted to pull in those changes as well? I've certainly used the menu app with the flashing_new instructions and it seems to work great on my c139.
-Craig
Hi,
I'm trying to get nuttx running on my C139 compal_e86(88?) phone. I have been reading some emails and loader scripts but am a bit unexperienced with this area of software. I've managed to use the "menu" app with flashing successfully but so far am unable to get nuttx to run either due to the compal loader not letting me load more than 128k into highram or the flash setup not being quite right in terms of loader scripts.
I think what I would like is this (based loosely on LINKAGE.txt in osmocom-bb/.../compal_e88)
- keep compal loader at 0x0- put something custom at 0x2000, either the menu app or a simple 2nd stage loader- put nuttx at 0x10000
The "menu" app option (http://bb.osmocom.org/trac/wiki/flashing_new) would require me to modify that code a bit so that I wasn't copying nuttx into highram but instead just running it "in-place" in flash. So maybe two header options: "highram:APPNAME" and "flash:APPNAME"? I suppose I could try running nuttx in highram as menu currently intends, by copying it from flash to ram but that seems sort of "wrong" if nuttx is my main goal.
The "other" option would be to write some simple loader for 0x2000 which did whatever setup might be required (none?) and simply jump to 0x10000. That way the ideas in LINKAGE.txt about safety and what-not are preserved. If I need to flash a new nuttx image I don't have to worry about ruining page 0 and compal loader and bricking the phone.
Another option would be to replace the compal loader but I'd rather get to nuttx sooner than later and don't see much immediate advantage to an entirely custom bootloader.
If I preserve the compal loader then all the normal osmocom-bb functionality is preserved in terms of being able to load layer1, rssi if you want to in highram while nuttx could be living in flash for booting into "normally" to use as a consumer-style device.
I think I prefer the "other" option I mention above to keep things fairly simple. Do you think I can just use the flash.lds from compal_e88, modify slightly for e86 (bigger IRAM I think is the only change) and simply put a jump at 0x2000 to 0x10000? Would that take care of exception vectors, setup and all the other stuff I don't currently understand about bringing things "up"?
Just FYI, I am working off the latest nuttx code and not nuttx-bb since nuttx-bb seems pretty out of date. Not sure what folks want to do with that.
Thanks,Craig
