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
Dear Osmocom community,
I would like to point out that at sysmocom, we're currently (again)
hiring [1]. If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.
sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project. Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.
Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.
We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G. We believe in
working upstream, no open core or dual licensing.
If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs(a)sysmocom.de
Thanks,
Harald
p.s.: I hope this kind of message is not disturbing to anyone. I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified. The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.
[1] https://www.sysmocom.de/jobs/
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
On 22 October 2017 at 19:20,
Snehasish Kar <snehasish.cse(a)live.com> wrote:
> Hello Vadim
>
> I tried using your trxcon along with grgsmtrx,
> but when i start the app mobile in the l2l3 software
> it gives me the following error:
>
> Assert failed !check_element_exists(cnode, cmd->string) command.c:627
> backtrace() returned 7 addresses
> /usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6]
> ./mobile() [0x43d371]
> ./mobile() [0x40548e]
> ./mobile() [0x4049e7]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45]
> ./mobile() [0x404a83]
>
> Please help.
Hi,
This message was forwarded to the ML. Please do the same
in the future to make others able to know about the problem
and possible solutions.
Actually, this crash isn't related to trxcon application
anyhow, it's caused by the recent libosmocore changes,
related to the VTY default nodes. A quick solution would
be to drop all custom 'exit' commands from the
'vty_interface.c'.
I'll try to fix the problem in spare time...
If you have some time and feel yourself able
to write a proper fix, just send me a patch,
and I'll review one ASAP ;)
BTW: we have some updates regarding to TX support.
Please look at the 'origin/ptrkrysik/trx' and
'axilirator/fixeria/trx' on GitHub.
With best regards,
Vadim Yanitskiy.
Hi,
Probably, the problem is related to https://osmocom.org/issues/1458
In short, a phone is unable to sync a strong BTS due to the ADC
input overload.
As a quick solution, you can use the 'stick ARFCN' option in 'mobile.cfg'.
This helped me when a phone was pretty close to my BTS.
With best regards,
Vadim Yanitskiy.
Dear List
I am trying to run osmocomBB with motorola c118 with openbsc.I tried to get
openbsc network on my phone it works well and I am able to register on
openbsc network.
But when i try to run osmocomBB with openBSC i am not able to get network.
Also when i run rssi firmware on c118 phone i get network and its working
fine.
I am using default configuration file for OpenBSC and using NanoBTS with
1800Mhz support.
Is there any configuration change is needed in openBSC ?
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
