I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi,
We have been working on the handover feature in OsmocomBB and have
managed to make some progress including SB/BSIC detection in dedicated mode
which was not previously being successfully done in firmware. I wanted to
share it and seek guidance on the last bit of handover implementation on
which we are stuck. I hope someone would be able to help us or make use of
our work.
We took code related to handover from the osmocom-bb jolly branch by
manually adding/deleting stuff in the master branch as updating to the
latest copy was giving us issues. We added code from the “Safely change TPU
offset on TS change or sync change” commit till the “Use only sel_si for
information about the current cell” commit. Using the handover code in the
jolly branch and after making the changes explained below we were able to
obtain the handover command from the BTS. The synchronized handover case
works sometimes though still not every time, however the non-synchronized
case doesn't work at all as we are not able to get the physical information
command from the new cell. I'll explain the changes/additions we made to
achieve this.
Firstly, we noted that in dedicated mode SB burst was not being detected.
Changes were required at three main places in order to correctly perform
FB/SB detection:
- It was seen that the results for SB were being read from DSP API location
dsp_api.db_r->a_sch which is for the idle mode. The results had to be read
from the dsp_api.ndb->a_sch26 location for the dedicated case if
TCH_SB_DSP_TASK is used.
- After reading the FB we needed to update the quarter-bit offset of the
TPU using the TOA of the FB to sync it with the start of frame of the
neighbour cell in order to catch the SB (by changing the vaule of
l1s.tpu_offset using the TOA of the FB).
- Frequency compensation needed to be performed using the afc_correct
function before reading the SB.
* We actually kind of cheated a bit by adding 3 frames to the original idle
frame in order to give us more time to perform FB/SB detection including
the synchronizations mentioned above. This was because we weren't that
proficient with the code and someone with more understanding could do this
better. The call did not get dropped. We used the initial added “idle”
frame to perform the quarter-bit and frequency compensation which was
reversed in the idle frame with the response function to tune back to the
serving cell.
These things, when added to the code did the trick and BSIC of the
neighbours was obtained.
Once the BSICs were decoded the measurement report sent to the BTS became
meaningful and the handover command was received. Upon receiving handover
command, access bursts needed to be sent on the new channel which again was
not currently being implemented properly as in order to tune to the new
cell we needed to know its quarter-bit offset for start of frame, frequency
compensation and absolute frame number which were not previously being
obtained. Now that we were able to detect FB and SB these values were
stored for the neighbours following detection of these bursts and were used
to tune to a neighbour cell in case of a handover to it before the sending
of access bursts. However, here is where we are stuck. We were expecting a
physical information message following the access bursts but were not able
to receive it due to which the handover failed. If only that could be
achieved we believe handover should be successful.
Either we are not syncing properly to the new cell or we might not be
following GSM protocol properly. We also might not be reading the FACCH
properly for physical information message after tuning to the new cell as
we couldn't really understand that bit very well. We wanted someone
expertise on this matter and were hoping our work could be of use. We were
more interested in getting the work done first up.
Best Regards,
M. Awais Aslam
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.
Hi. My name is tyrus and I have been working with OsmocomBB since 2014 but
had given it a break. I decided to go back to the project only that this
time I am running a machine on Ubuntu 16.04 LTS.
I get the following error during the make stage of the installation:
libmobile.a(gsm48_rr.o): In function `gsm48_rr_enc_cm3':
*/home/tyrus/osmocom-bb/src/host/layer23/src/mobile/gsm48_rr.c:1210:
undefined reference to `bitvec_fill'*
*libmobile.a(vty_interface.o): In function `cfg_ms_rename':*
*/home/tyrus/osmocom-bb/src/host/layer23/src/mobile/vty_interface.c:1283:
undefined reference to `osmo_talloc_replace_string'*
collect2: error: ld returned 1 exit status
Makefile:377: recipe for target 'mobile' failed
make[3]: *** [mobile] Error 1
make[3]: Leaving directory
'/home/tyrus/osmocom-bb/src/host/layer23/src/mobile'
Makefile:322: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/tyrus/osmocom-bb/src/host/layer23/src'
Makefile:348: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/tyrus/osmocom-bb/src/host/layer23'
Makefile:84: recipe for target 'host/layer23/layer23' failed
make: *** [host/layer23/layer23] Error 2
Anyone else experienced this? I have *gcc-arm-none-eabi* toolchain
installed
Much appreciated.
-ty
Hi
My name is Mohsen Asghari, master student in Computer EngineeringI have to create a communication center based on GSM with OpenBTS,everything is OK, I have tested osmocom-bb with SMS in vty and it was perfectbut there is call problem. in both of real and virtual network this problem is bothering me finishing my thesiscan you help me understand whats wrong with my packages and installation?
it is five months that I am trying to fix this problem but I cant.in the cm-service command I have a channel release from ms which the comments shows that the problem is about there is no free socket for voice....! _____________
yours sincerely,
Mohsen Asghari
Hello, I am from Russia, can you help me with Filter Replacement!
I have to mobile, Motorolla C115 and C118. I was bye all elements to make filter replacement. Motorolla C115 look like your instruction and I was done filter replacement. Motorolla C115 nice work after it. But Motorolla C118 don`t look like in your instruction. I read:
"Different circuit
Sometimes the input (at the bottom of the balun) is not with caps in series and a resistor in parallel. Instead it might be without the resistors in parallel and resistors in series. Remove the resistors and place 2x the appropriate cap in series (22 pF for GSM90, 15 pF for DCS1800". But I don`t understand what I must do. I do like my picture (С118_2.jpg), but after it Motorolla don`t work: No signal from Network.
Can you help me?
With Best Regards, Oleg Syvorov
Dear Osmocom community,
from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org
redmine could not send any e-mails. This was due to a configuration
file syntax error introduced by me, my apologies.
If you rely on redmine e-mail notifications to the issues you have
subscribed to, please double-check as related notifications during that
interval were unfortunately lost.
Best regards,
Harald
p.s.: The reason for the config change was to enable e-mail
notifications from jenkins.osmocom.org (which it now has, if you want to
configure e.g. post-build notification actions).
--
- 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 this error when I try to choose channel of baseband near me:
<000c> l1ctl.c:114 FBSB RESP: result=255
I'm using Motorola C115 Phone, flashed layer1.compalram.bin, burst_ind branch
Are there any solutions of this problem?
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hi,
> And I found it's possible to acrivate some setting in
> OnmoNITB but how can I do the actual request? I cannot
> find anything in the user manual, vty manual or in the menu...
This request is being sent automatically every time when
a dedicated channel between MS and BTS is established.
With best regards,
Vadim Yanitskiy.
Dear developers,
I found that RRLP requests are possible within OsmoNITB.
http://security.osmocom.org/trac/wiki/RRLP
The popular Free Software implementations of the GSM network OpenBSC
<http://openbsc.osmocom.org/> and OpenBTS
<http://openbts.sourceforge.net/> both
support RRLP inquiries to mobile phones
And I found it's possible to acrivate some setting in OnmoNITB but how can
I do the actual request? I cannot find anything in the user manual, vty
manual or in the menu...
Thanks in advance!
