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.
Dear Osmocom community,
I have been working on GAPK (GSM Audio Packet Knife) for some
time, and now I would like to share some achievements.
Previously GAPK was represented as a single binary that
could be called with some command line arguments in order
to perform required operations. This is only handy for
humans, but not for other programs, which may also need
to perform some format / codec conversations or audio
capture / playback.
One of such programs is the mobile from OsmocomBB project.
Currently, when you're making a voice call, both audio
capture and playback are only possible on the L1 side,
i.e. on a Calypso based phone. Of course, the audio stream
can be redirected via MNCC socket, but this is not what
a regular OsmocomBB user would like to do. Moreover, there
is a lack of AMR codec support.
Also, there is another GNURadio based project named GR-GSM.
In short, this is a set of blocks for GSM signal reception,
demodulation and further processing. At the moment, one has
TCH Full Rate decoding capabilities only. Audio playback is
not supported yet.
Having these projects in my mind, I have got an idea of
creating a shared library from the GAPK source code. And,
a few days ago I was managed to get the audio playback
working in OsmocomBB. I hope, this library will be also
usable for other projects.
Brief list of changes were made:
- Composed a shared library named libosmogapk
- All exposed symbols have got an 'osmo_gapk' prefix
- Added a pkg-config manifest and a symbol export map
- Integrated the Osmocom logging framework
- Benchmarking is now disabled by default
- Processing queue now based on the linuxlist
- Fixed program exit due to ALSA buffer underrun
- Fixed ALSA audio playback from file
- Old gapk application was renamed to 'osmo-gapk'
and linked against the library
- Adjusted verbosity level (normal / debug)
- Fixed I/O combinations (ALSA, RTP, file...) check
All changes could be found at the fixeria/lib branch of GAPK.
I hope to see them merged, and open for discussions ;)
With best regards,
Vadim Yanitskiy.
Hey,
I think I have the minimal patchset to add primitives and lua
bindings to have useful functionality and know what is good/bad
with it and extend/iterate it from here. I would like to share
the state and what's next. On the higher level we have:
* Primitive for timers
* Primitives OP_IND for started/shutdown handling
* Primitives OP_IND for SMS status and RX SMS
* Primitives OP_IND for Mobility Management state changes
Next steps:
* Pack MNCC and enable/handle voice calls as well to do
call control.
What needs to change in future iterations:
* SMS, MM, started/shutdown indications should be async.
Especially for MM handling that will do further state changes
from within the new_mm_state. So if we enable/disable the MS
within this callback we ask for trouble.
* The lua scripting code is calling some routines directly. E.g.
for a "simple" SMS sending routine, to query state. This should
probably be converted to primitives as well. But that can be done
while keeping the lua API (e.g. with continuations or cache the
MS status).
* Finish the OsmocomBB manual documentation for the API
* Bikeshed. Number vs. Bool... ;)
Bugs found by scripting:
* I found an ASAN issue in mobile (fix pending)
* Noticed paging with outdated TMSI on NITB
* Trying to encode an alphabetic phone number causes issue in
libosmocore (bug report pending)
cheers
holger
Examples:
# Print through logging framework
print("Hello from Lua");
log_notice("Notice from lua");
log_debug("Debug from Lua");
log_error("Error from Lua");
log_fatal("Fatal from Lua");
# Start a timer... and cancel it. Notice the ':'
local timer = osmo.timeout(1000, function()
print("After timeout!!!")
end)
timer:cancel()
# Access a osmo.ms() singleton table/object
print("MS", type(osmo.ms()));
osmo.ms():imsi()
osmo.ms():imei()
osmo.ms():shutdown_state()
osmo.ms():started()
osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23)
osmo.ms():start()
osmo.ms():shutdown(force)
# Callbacks...
function ms_started_cb(started)
end
function ms_shutdown_cb(old_state, new_state)
end
function sms_cb(sms, cause, valid)
for i, v in pairs(sms) do
print(i, v)
end
end
function mm_cb(new_state, new_substate, old_substate)
if new_state == 19 and new_substate == 1 then
osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23)
end
end
local cbs = {
Started=ms_started_cb,
Shutdown=ms_shutdown_cb,
Sms=sms_cb,
Mm=mm_cb
}
osmo.ms():register(cbs)
Hi Mychaela,
Great work! I just had a quick look and did some tests.
Do you agree if I would merge your changes to the mainstream
under GNU GPL version 2 license, keeping you as the author?
With best regards,
Vadim Yanitskiy.
Hi,
while I am adding scripting support to the mobile application I tried using a primitive interface between the scripting implementation and the mobile application. On new indications a callback in the primitive interface user will be invoked and there is a generic submit function that will dispatch (switch/case) over the primitive and call the right internal functions. To prototype this I have implemented "timer" support, SMS and the started/shutdown handling through primitives.
The neat thing about this approach is that I don't tie a specific scripting solution into the code, the indications are generic enough to be useful in multiple contexts, the submit/dispatch is about high level operations ("send SMS", "switch device off") that map to other programming languages as well. E.g. it is easy to imagine that one writes a TCP/IP adapter to send these primitives to another process/application.
The controversial part is that this code is not using a msgb. Normally the primitive header is inside a msgb and then more or less points to itself. But in the scripting layer case the "timer", "new sms", "network selection" are already fully parsed objects (or where never parsed from a network representation) so are normally not located in a msgb in any form.
One option is not to bother and deal with the primitive header just being embedded in another structure. The concept of request/response/indication is bigger than network messages.
The other is to create a dummy msgb to obey the interface and follow the existing users but I am not sure what we would gain.
For XYZ->internal we can use direct function calls and avoid the indirection of the primitives and for indications either call directly into the scripting code or create a script_indications struct and put it into the struct osmocom_ms. Only downside that doing RPC requires more work? So far I only forsee a single "script_indications" callback.
comments? opinions?
holger
Hello OsmocomBB community,
Now that the software issues have been solved with my obb-fcmods-r1
release, there is only one remaining feature of the historical Mot C1xx
phones that is not matched by the newly-made FCDEV3B product: support
for the GSM850 band. Mot C1xx phones were made in 900+1800 MHz and
850+1900 MHz versions; my current FCDEV3B is 900/1800/1900 MHz triband,
but no 850 MHz band.
I could easily produce an 850/1800/1900 MHz version of the FCDEV3B if
I knew which SAW filter part number I should populate instead of the
EGSM downlink band B7820 filter which currently sits in the low band
Rx path. But I don't know this part number. I know that Openmoko
produced both 900/1800/1900 MHz and 850/1800/1900 MHz versions of
their GTA02 by populating different SAW filter parts onto the same PCB
footprint, but I only know the part number for the EGSM downlink band
filter (B7820, populated on current FCDEV3B boards), but not the one
for the GSM850 downlink band.
I looked at the schematics for a later quadband board from TI
(I-Sample, LoCosto chipset), but the SAW filters used there have a
different PCB footprint (smaller), hence their part won't work.
So, would anyone happen to know a part number for a GSM850 downlink
band SAW filter (be it the same one as used by Openmoko or a different
one) in the same physical package as the B7820, B7821 and B7851 for
EGSM, DCS and PCS downlink bands?
TIA,
Mychaela
Hello OsmocomBB community,
I have just produced a modified version of the Calypso target fw part
of OsmocomBB, adding proper support for the FCDEV3B board target and
also bringing the pre-existing Calypso targets up to par while at it.
You can find it here:
ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/obb-fcmods-r1.tar.bz2
obb-fcmods-r1 stands for "OsmocomBB with FreeCalypso modifications,
release 1". Here are the main changes relative to mainline OsmocomBB,
quoted from the README file inside the tarball:
* Added support for FreeCalypso FCDEV3B target, target name fcdev3b, new
board/fcdev3b directory, compiling into board/fcdev3b/layer1.highram.bin.
* Fixed GPIO and ASIC_CONF_REG configuration on the pre-existing Openmoko GTA0x
target: very similar to our own FCDEV3B, but not identical.
* Fixed ASIC_CONF_REG setting on the Pirelli DP-L10 target to match what
Pirelli's official fw sets.
* Implemented reading of factory RF calibration values, not only on our own
FCDEV3B, but also on the pre-existing Motorola C1xx, Openmoko GTA0x and
Pirelli DP-L10 targets.
* The old OsmocomBB Tx power level control code and tables have been removed
entirely and replaced with new logic that exactly matches what the official
chipset firmware (TI/FreeCalypso) does, using tables in TI/FreeCalypso
format. These tables are normally populated with factory-programmed RF
calibration values on all supported targets. Compiled-in tables serve as a
fallback and match each target's respective original fw.
* A different AFC slope value is used on different targets; OsmocomBB's
original value was/is only correct for the Mot C1xx family, whereas
GTA0x/FCDEV3B and Pirelli DP-L10 need different values because Openmoko's
VCXO (copied on the FCDEV3B) and Pirelli's VCTCXO are different from what
Motorola used.
* The initial AFC DAC value for the FB search is taken from factory calibration
records on those targets on which it has been calibrated per unit at the
factory.
The tarball contains a source + build products tree, i.e., ready-to-use
board/*/layer1.highram.bin images are included. They have been compiled
with Tx support enabled.
Happy hacking,
Mychaela
