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
Hello OsmocomBB community,
I am the manufacturer of a GSM mobile station development board based
on the Calypso+Iota+Rita chipset from TI. The hardware product in
question has been created for the primary purpose of running the
end-use-oriented GSM+CSD+GPRS modem firmware that was previously
maintained by TI and whose maintenance has since been taken over and
continued by FreeCalypso, but being based on the Calypso chipset, my
board is also capable of running OsmocomBB. The purpose of the
present inquiry is to find out whether this hardware product might be
of interest to the OsmocomBB community, or if those who wish to run
OsmocomBB (as opposed to TI-based FreeCalypso firmware) would be
better advised to use an SDR device instead.
As I understand it, there are two reasons for why the original
incarnation of OsmocomBB (prior to the recent addition of SDR PHY
support) used Calypso phones as its physical transceiver instead of
USRP-style SDR devices: (1) the work done by the Calypso DSP is
already done, hence there was less work for OsmocomBB developers to
do, and (2) Calypso phones used to be dirt-cheap, whereas SDR devices
cost some non-trivial money.
But the dirt-cheap Calypso phone situation is now firmly in the past,
and newly made Calypso devices like my FCDEV3B are nowhere close to
cheap. The qty-1 retail price for one of my FCDEV3B boards is
$500 USD; if someone were to order a large batch (say, 100 boards),
I am reasonably confident that the per-unit price can be brought down
to $300 USD or maybe even lower, but getting any kind of firm numbers
beyond a guesstimate would require actual work, and that work will
only be done if I receive some expression of serious and genuine
interest. But even if we manage to bring the price down to, say, $200
per board with a really large order quantity, it *still* won't be
anywhere near as cheap as old Calypso phones used to be, and the price
is still essentially in the same ballpark as a midrange SDR device.
Thus with the cost of an SDR device and that of a newly made Calypso
device being comparable (or as things stand presently, the Calypso
option is more expensive), is there any remaining reason to use
Calypso devices as opposed to SDR PHY for OsmocomBB? In other words,
is there any solid technical reason (not involving cost) to prefer a
Calypso device over SDR PHY for OsmocomBB purposes, or is there not?
Which translates into: is there any reason to support running OsmocomBB
on FreeCalypso hardware and to market such hw to the OsmocomBB
community, or would it be better to tell people that if they want
OsmocomBB, they should use an SDR PHY, and leave FC hardware for
people like me who are interested in end use applications (as opposed
to hacking) using TI-based FC firmware?
One argument I have heard against the use of SDR for GSM MS role is
that SDR devices supposedly have a difficult time retuning every
4.615 ms, and thus would have a difficult time connecting in the MS
role to a GSM network that employs frequency hopping. Is there any
truth to that argument, or has that problem already been solved? Are
there any other areas in which a chipset like the Calypso that is
specifically designed for the GSM MS role would perform better than an
SDR device of the kind that are viable cost competitors against newly
made Calypso hardware?
Just seeking some clarification...
M~
P.S. Before anyone says that Calypso chips themselves are no longer
made and thus don't constitute a viable option, please note that I can
still buy them on the Chinese grey market at least in tens of thousands
of pieces, maybe more, and there is no conceivable way that all current
phone hacking and phone liberation communities combined can produce
enough demand to exhaust that supply. And if someone does order 100
thousand Calypso boards at $300 or so apiece, that would be more than
enough money to hire a pirate chip fab to clone every chip in the
Calypso chipset.
Hello Mychaela,
First of all, my congratulations! I have been watching the project
you lead for some long time, and it's great to see your achievements.
> As I understand it, there are two reasons for why the original
> incarnation of OsmocomBB (prior to the recent addition of SDR PHY
> support) used Calypso phones as its physical transceiver instead of
> USRP-style SDR devices: (1) the work done by the Calypso DSP is
> already done, hence there was less work for OsmocomBB developers to
> do, and (2) Calypso phones used to be dirt-cheap, whereas SDR devices
> cost some non-trivial money.
Yeah, moreover I think when OsmocomBB was initiated, the prices of
available SDR hardware were higher, than today...
> Thus with the cost of an SDR device and that of a newly made Calypso
> device being comparable (or as things stand presently, the Calypso
> option is more expensive), is there any remaining reason to use
> Calypso devices as opposed to SDR PHY for OsmocomBB? In other words,
> is there any solid technical reason (not involving cost) to prefer a
> Calypso device over SDR PHY for OsmocomBB purposes, or is there not?
Personally, for research and development purposes I would preffer SDR.
The main reason is that my research scope isn't limited by GSM only,
there are other pretty interesting technologies like Iridium, TETRA,
GMR, and of course UMTS followed by LTE.
> Which translates into: is there any reason to support running OsmocomBB
> on FreeCalypso hardware and to market such hw to the OsmocomBB
> community, or would it be better to tell people that if they want
> OsmocomBB, they should use an SDR PHY, and leave FC hardware for
> people like me who are interested in end use applications (as opposed
> to hacking) using TI-based FC firmware?
SDR PHY isn't finished yet. We only managed to get actual burst
transmission working only a couple of weeks ago. At the moment,
both AGC and Timing Advance loops are missing, and TX power is
not high enough to 'deal' with real base stations...
So, I think, Motorola C1XX phones remain the primary hardware
back-end for now, thus would be better to tell people about them.
> One argument I have heard against the use of SDR for GSM MS role is
> that SDR devices supposedly have a difficult time retuning every
> 4.615 ms, and thus would have a difficult time connecting in the MS
> role to a GSM network that employs frequency hopping. Is there any
> truth to that argument, or has that problem already been solved? Are
> there any other areas in which a chipset like the Calypso that is
> specifically designed for the GSM MS role would perform better than an
> SDR device of the kind that are viable cost competitors against newly
> made Calypso hardware?
Yeah, both frequency popping and neighbour power measurement are the
hard topics for SDR PHY. There are some ideas how to implement that,
but right now we are keeping this problem aside until all the rest
is done ;)
With best regards,
Vadim Yanitskiy.
Hi,
as part of adding bindings I wrote code that is doing shutdown/no shutdown every second. Actually I call mobile_init/mobile_exit with a script like this:
local start = false
osmo.ms().start()
function toggle_it()
osmo.timeout(1, function()
if start then
start = false
osmo.ms().start()
else
start = true
osmo.ms().stop()
end
toggle_it() -- start the timer again
end
end
toggle_it()
And while debugging I have nothing connected for the l1ctl. This means the l1ctl reset ack is not being received by the application. So when doing the above the following happens.
mobile_init()
mobile_exit()
mobile_init()
|-> busy loop of adding a timer already in the tree
Turns out that mobile_exit checks the state and then takes an early exit without stopping the timers. So let's use the force option that is meant to not send a IMSI detach. Let's try it again.
mobile_init()
mobile_exit()
mobile_init()
|-> busy loop of adding a timer already in the tree
Why is that? Even force mobile_exit() will exit early and mobile_init() doesn't take the device out of shutdown. From my point of view a mobile_exit(ms, force) should really take the device down and never fail. Any objections to modify the code for this?
regards
holger
