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
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>
Can you help me?
-------- Пересылаемое сообщение --------
От кого: Олег Суворов <olegtsss(a)mail.ru>
Кому: baseband-devel <baseband-devel(a)lists.osmocom.org>
Дата: Пятница, 1 сентября 2017, 18:28 +06:00
Тема: help me
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
----------------------------------------------------------------------
----------------------------------------------------------------------
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,
> I believe I need to keep focusing on osmo-trx support
> as the gr-gsm app does not seem to support TX (please
> correct me if I'm wrong though).
You are right, currently it doesn't. But we together with
Piotr Krysik are working on TX support for GR-GSM...
> I will keep investigating this and I will provide you
> some patches for osmo-trx which enable power
> measurement and synchronization.
Great! Having both OsmoTRX and GR-GSM TRX support would
be good. I am currently busy with TCH implementation for
trxcon, so as soon as I finish, I'll put my development
power on this too.
With best regards,
Vadim Yanitskiy.
Hi Adrian,
> I am interested in the sdr_phy work being done currently
Great to hear that.
> I built osmo-trx from the ms branch and implemented a crude
> power measurement command. When running trxcon everything works
> fine, I get power indications for channels, and then when the
> mobile app is trying to sync to an ARFCN I start having issues.
I have never developed / tested trxcon with OsmoTRX so far.
Currently I am using GR-GSM as a L1 back-end, and the virtual
connection between OsmocomBB and OsmoBTS during development.
In general, trxcon should be able to 'speak' with OsmoTRX,
because one do use classical transceiver UDP interfaces. But
there are some CTRL commands, which aren't implemented in OsmoTRX
yet (such as ECHO and MEASURE).
> I had to change the code of trxcon in order for SCH to work,
> because the bit values were inverted (0 was 1 and viceversa).
> I am attaching the changes at the end of the message.
Sounds strange. In case of virtual Um-interface (FakeTRX) and
GR-GSM TRX all SCH messages are decoded correctly. I will look
closer to this issue, thanks anyway!
> It appears as if the deinterleaving in gsm0503_xcch_decode
> does not work... could be the order of bursts?
The order of bursts should be consistent, I mean frame-by-frame.
You need to make sure that a frame number from SCH burst is being
decoded correctly by OsmoTRX. Every burst coming from OsmoTRX
has a header with frame number, which is used by trxcon to
determine a current frame position within a multiframe.
Probably, the problem is due to incorrect / consistent
frame number values. The internal clock counter (sched_clck.c)
is only used to schedule the UL bursts transmission.
> I'd appreciate any help here. I'm also ready to share the
> changes I've made to osmo-trx/ms and trxcon.
For now, have a look at:
- GR-GSM based transceiver:
https://github.com/axilirator/gr-gsm/tree/fixeria/trx
- Virtual Um-interface (brief description):
http://git.osmocom.org/osmocom-bb/tree/src/target/fake_trx/README?h=fixeria…
- The latest version of trxcon (use fixeria/fake_trx branch):
http://git.osmocom.org/osmocom-bb/log/?h=fixeria/fake_trx
You can also join the development process, feel free to mail me.
I will create the wiki page as soon as possible.
With best regards,
Vadim Yanitskiy.
Hello,
I am interested in the sdr_phy work being done currently, and I'm
trying to get it set up on my computer. I built osmo-trx from the ms
branch and implemented a crude power measurement command. When running
trxcon everything works fine, I get power indications for channels,
and then when the mobile app is trying to sync to an ARFCN I start
having issues.
The FCCH bursts are decoded fine, and so are the SCH bursts (which I
can also see in the osmo-trx terminal). I had to change the code of
trxcon in order for SCH to work, because the bit values were inverted
(0 was 1 and viceversa). I am attaching the changes at the end of the
message.
Unfortunately, the BCCH and CCCH bursts are not decoded:
<0006> sched_lchan_sch.c:98 Received SCH: bsic=30, fn=1116799, sched_fn=1116798
<0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116800 ts=0 bid=0
<0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116801 ts=0 bid=1
<0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116802 ts=0 bid=2
<0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116803 ts=0 bid=3
<0006> sched_lchan_xcch.c:117 Received bad data frame at fn=1116800
(2/51) for BCCH with 66 errors
It appears as if the deinterleaving in gsm0503_xcch_decode does not
work... could be the order of bursts?
I'd appreciate any help here. I'm also ready to share the changes I've
made to osmo-trx/ms and trxcon.
Best regards,
Adrian
diff --git a/src/host/trxcon/trx_if.c b/src/host/trxcon/trx_if.c
index 6a84af6..def571c 100644
--- a/src/host/trxcon/trx_if.c
+++ b/src/host/trxcon/trx_if.c
@@ -325,6 +325,11 @@ int trx_if_cmd_setslot(struct trx_instance *trx,
uint8_t tn, uint8_t type)
return trx_ctrl_cmd(trx, 1, "SETSLOT", "%d %d", tn, type);
}
+int trx_if_cmd_sync(struct trx_instance *trx, uint8_t type)
+{
+ return trx_ctrl_cmd(trx, 1, "SYNC", "%d", type);
+}
+
/*
* Tuning Control
*
@@ -392,7 +397,7 @@ int trx_if_cmd_measure(struct trx_instance *trx,
LOGP(DTRX, LOGL_ERROR, "ARFCN %d not defined\n", arfcn_start);
return -ENOTSUP;
}
-
+ trx_ctrl_cmd(trx, 1, "RXTUNE", "%d", freq10 * 100);
return trx_ctrl_cmd(trx, 1, "MEASURE", "%d", freq10 * 100);
}
@@ -421,6 +426,7 @@ static void trx_if_measure_rsp_cb(struct
trx_instance *trx, char *resp)
arfcn == trx->pm_arfcn_stop);
/* Schedule a next measurement */
+ usleep(50000);
if (arfcn != trx->pm_arfcn_stop)
trx_if_cmd_measure(trx, ++arfcn, trx->pm_arfcn_stop);
}
@@ -558,9 +564,9 @@ static int trx_data_rx_cb(struct osmo_fd *ofd,
unsigned int what)
/* Copy and convert bits {254..0} to sbits {-127..127} */
for (i = 0; i < 148; i++) {
if (buf[8 + i] == 255)
- bits[i] = -127;
+ bits[i] = 127;
else
- bits[i] = 127 - buf[8 + i];
+ bits[i] = -127 + buf[8 + i];
}
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 (no network signal or network signal is 1 level from 5).
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 (your network email network filter doesn`t allow me to download my photo, but I can send it if you allow this), but after it Motorolla don`t work: No signal from Network (or network signal is 1 level from 5).
Can you help me?
With Best Regards, Oleg Syvorov
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!
Hi,
> Is it possible to manually give the MS a timeslot number to listen
> to after it has performed location update ?
Yes, you can. See the L1CTL_DM_EST_REQ in L1CTL protocol
implementation. But keep in mind, that as soon as you switch
your phone to another timeslot (other than BCCH), you will be
unable to 'hear' Paging Requests.
Regarding to your initial question, you was asked to provide the
traffic dumps, but there are still nothing. So, it's still difficult to
understand, what's happening on your side :/
With best regards,
Vadim Yanitskiy.
Hi,
Don't get me wrong, but your current description sounds like
"I have a problem, but I wouldn't say any details about that".
Please provide at least mobile application logs, and also try
to figure out some things yourself:
1) What is difference between both SIM cards you use?
2) Does mobile with "non-working" SIM perform successful LU?
3) Does mobile with "non-working" SIM receive any Paging Request?
4) Does one answer to Paging Request by sending Paging Response?
5) Then, does the L1 switch to a dedicated channel?
6) What is happening on a dedicated channel?
7) ... ?
OsmocomBB is not for end users, so you should do / learn a lot
of things yourself. After all, the source code is always available.
With best regards,
Vadim Yanitskiy.
Hi!
Next to the announcement (http://osmocom.org/news/75) I've put together
some guide in the wiki as to how the Virtual Um interface can be used
with the osmo-bts-virtual, virtphy and mobile programs running all on
your local PC:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
Feel free to try it out and/or improve the wiki page and/or let me know
if something is not sufficintly clear. I intentionally don't want to
repeat general information about configuring OsmoNITB or using
OsmocomBB. The above-mentioned page should only document those aspects
that are different from the classic setup with real hardware.
I'm now investigating some more of the bugs I'm starting to find with
using the VirtualUm interface from my related TTCN-3 testsuite, at this
time particularly https://osmocom.org/issues/2380
Will document that testsuite once it can actually run as expected.
Regards,
Harald
--
- 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)
Hi Sebastian and team,
I've been thinking a bit on how to implement many concurrent OsmocomBB
instances in a setup where we use Sebastian's OsmocomBB virt_phy and
osmo-bts-virtual.
The point of having virtual mobile phones is that you can easily
simulate many. Many more than you can easily physically manage, so I'm
thinking definitely of hundreds and preferably thousands of MSs. This
way we can easily simulate load on BTSs, use up all channels, get in
overload situations where we have to reject immediate assignments, etc.
Right now, the data structures in virt_phy are a bit convoluted, and
there is no clear separation between the state of the actual GSMTAP
socket and the MS-specific state attached to one given L1CTL connection.
So if you want to run multiple MS, it seems currently one would have to
run multiple pairs of { virt_phy, mobile }, one pair for each MS. This
leads to a rather large set of processes, and all have to process their
own copy of the same UDP messages received on the multicast socket.
connection-oriented unix domain sockets can very well handle multiple
connections (similar to a single TCP server being able to acccept many
incoming connections). So if the MS-specific state (like the scheduler
/ L1CTL related state) is properly separated from the GSMTAP side, any
number of "mobile" programs (or other L1CTL users) could actually
connect to the same virt_phy program and share it.
Do you think this is worth it? I would really like the idea of just
having to start one program, and not having to configure each "mobile"
instance with a different l1sap socket name, manage to close the
processes vice-versa, etc.
Theoretically one could stay in the current 1:1 model, but I somehow
find 1:N more appealing.
Regards,
Harald
--
- 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)
Hi Piotr,
I just wrote a simple (more or less working) GNURadio block for
connection with OsmocomBB. It is named "TRX Interface" and currently
only capable to transform (in Osmocom bursts are followed by a bit
different header) and send received bursts through the UDP link.
If you remember, I had a problem with UDP source port. So, I spent
some time and finally solved this challenge. My first idea was to
inherit the existing 'Socket PDU' implementation and I started to
look for a way I could do that. After a few minutes of searching,
I have found your mails with the same question, and a brief answer
from Sylvain, that it is impossible :(
So, I have copied actual implementation, stripped out everything
related to TCP and implemented a feature to set UDP source port.
Now I am able to receive all DL bursts, coming from GR-GSM to my
trxcon application.
At the moment I am working on TDMA scheduler, which is almost
finished. It's time to start writing GR-GSM blocks for burst
transmission. The following thoughts / questions are in my mind:
- TX should be simpler than RX, because we don't need to detect
bursts and correct any errors.
- Both receiver and transmitter should be time synchronized.
I think, the SCH clock from the 'GSM Receiver' block may be
easily shared. Moreover, actual clock indications could be
forwarded to my block.
- If I am correct, to transmit a burst, one should be converted
to symbols. How can we do that?
- We cannot simply use the existing 'GMSK Mod' block, because
GSM uses TDMA. Right? If so, point me to the right direction.
P.S. This message is posted at the baseband-devel mailing list.
With best regards,
Vadim Yanitskiy.
Hi Harald and Sebastian,
> Some of you will have alrady noticed, over the last few days I reviewed,
> cleaned up, submitted and merged the virtual Um interface support on
> both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
First, my congratulations to Sebastian, great work! I also would like to
add my two cents to this topic. As we already discussed with Harald, the
virtual Um-interface could be helpful for testing, so I have some ideas
regarding to this application.
Regarding to the previous topic, where the problem of multiple BTS and
multiple MS was discussed. I am not going to say, than my implementation
of virtual Um-interface is better or worse. Moreover, one was created
for my personal requirements just for testing of some code parts I am
currently working on. Instead of that, I would like to do some relative
analysis of both implementations:
- At the moment, my implementation do support only a single MS <-> BTS
connection. But, I have been writing all the code as modular as
possible, so handling multiple L1CTL connections at the same socket
(/tmp/osmocom_l2) could be added by a few lines of code. Currently
the L1CTL link handler discard any incoming connections if there is
already established one. This behaviour could be changed to accept
more than one connection, allocating dedicated set of structures
(trx interface, scheduler stuff, etc.) for each.
- Regarding to the current state of work, I have xCCH RX / TX working,
so L23 applications are capable to establish a dedicated channel and
perform regular operations like: LUR, USSD, SMS, etc. Right now I am
woring on TCH, relaying at OsmoBTS source code. As I know, mobile app
can be connected to Linux Call Router, so this could be used for TCH
testing (high load if required).
- As I use OsmoTRX style transceiver interface for OsmocomBB, no changes
are required on OsmoBTS side. All bursts are being forwarded from BTS
to MS and vice versa through a simple Python application. From the
other side, this limits us to use osmo-bts-trx with its compatibility
issues. If you think, why Python? I've choosed this language because
of implementation speed - first working code was ready after a hour
of work. CPU load is about 2%, the most hungry is a clock generator.
Anyway, it can be easily reimplemented in C for better performance.
So, if you guys think that this implementation could be useful for high
load / regression testing too, just let me know, and I'll do required
changes in the source code.
With best regards,
Vadim Yanitskiy.
Hi all!
Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.
This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves. While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.
If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
BSC/NITB, just like with real hardware
OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route. You
should see the GSMTAP frames in wireshark.
On the OsmocomBB side, simply start the virt_phy binary. It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile". Once virt_phy is running, you can
start "mobile" just like with real hardware. The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.
Everything from this point on is just normal. You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work. Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.
If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.
My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
to different config files, ensuring that all related bits are set
correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping
This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.
In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.
Regards,
Harald
--
- 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)
Hi,
Which USB-TTL converter do you use?
What is the output of PuTTY and mincom? Post it here.
Try using -m c123 instead of -m c123xor
KR,
Anton
2017-06-05 8:30 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
> HI again,
>
> I replaced my ttl converter, now my phone is able to communicate via
> serial port but osmocon is unable to write hello world binary. The output
> of following command is given
>
> $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/
> compal_e88/hello_world.compalram.bin
>
>
> output:
>
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 3 bytes from modem, data looks like: 82 bf 7d ..}
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: ff .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
>
>
> and output on putty is unreadable. Kindly guide me what's wrong and how
> can it be fixed.
> Thanks
>
> On Thu, Jun 1, 2017 at 12:39 PM, Anton Gorbachev <antgorka(a)gmail.com>
> wrote:
>
>> If you cannot get @ftmtoolerror with minicom then your jack is NOT
>> working or your TTL converter is broken (was burnt during soldering?:)
>>
>> If you have another OS (e.g. Windows machine) you can put the device in
>> the PC, find out which serial line it is using,
>> run PuTTY, set Destination to Serial, COM9 (or what you find out),
>> speed 115200, connect.
>> Then push the power button on motorola, you must see @ftmtoolerror there.
>> If not, try another jack, another TTL converter, remove phone plastic case
>> as I told already..
>>
>> No more ideas :)
>>
>> KR,
>> Anton
>>
>>
>> 2017-06-01 10:27 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>
>>> Oh okay. The headphone jack is working fine, i have tested it. And
>>> helloworld isn't working. Can you tell some other method to test phones
>>> connectivity with my system.
>>>
>>> On Thu, Jun 1, 2017 at 12:16 PM, Anton Gorbachev <antgorka(a)gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Check the picture
>>>> https://osmocom.org/attachments/download/2091/motorola_c123_
>>>> hello_world.jpg
>>>>
>>>> I mean the outer plastic case of the phone may not allow your jack to
>>>> be inserted at the whole length to thoe whole even if it looks like OK.
>>>> It depends on your jack case shape.
>>>>
>>>> KR,
>>>> Anton
>>>>
>>>> 2017-06-01 9:57 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for replying back.
>>>>>
>>>>> I am not using virtualized environment. No success with minicom test.
>>>>> What exactly do you mean by jack is being plugged on the whole length, i
>>>>> didn't get it.
>>>>>
>>>>>
>>>>> On Thu, Jun 1, 2017 at 11:16 AM, Anton Gorbachev <antgorka(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Are you sure the jack is being plugged on the whole length?
>>>>>> Did you get success with minicom test?
>>>>>> I would recommend you to disassemble phone and check whether the jack
>>>>>> plugged an the whole length.
>>>>>> Do you use virtualized OS or normal? If virtualized, try to play with
>>>>>> the settings.
>>>>>>
>>>>>> KR,
>>>>>> Anton
>>>>>>
>>>>>> 2017-06-01 7:30 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to write osmocombb to Motorolla c118 phone by following
>>>>>>> the given [1] guide.I have successfully compiled firmware binaries but
>>>>>>> having issues while writing them to phone.
>>>>>>>
>>>>>>> I connected motorolla c118 via USB Serial To RS232 TTL to 2.5mm
>>>>>>> audio jack, using the given guide [2]
>>>>>>>
>>>>>>> When I run this command
>>>>>>>
>>>>>>> $ dmesg | grep tty
>>>>>>>
>>>>>>> I get the following output
>>>>>>>
>>>>>>> [ 0.000000] console [tty0] enabled
>>>>>>> [ 14.946936] usb 3-6: pl2303 converter now attached to ttyUSB0
>>>>>>> [ 973.747957] pl2303 ttyUSB0: pl2303 converter now disconnected
>>>>>>> from ttyUSB0
>>>>>>> [ 1484.595816] usb 3-6: pl2303 converter now attached to ttyUSB0
>>>>>>> [ 1845.344494] pl2303 ttyUSB0: pl2303 converter now disconnected
>>>>>>> from ttyUSB0
>>>>>>> [ 2643.566407] usb 3-6: pl2303 converter now attached to ttyUSB1
>>>>>>>
>>>>>>> And on running this
>>>>>>>
>>>>>>> $ sudo cu -l /dev/ttyUSB1 -s 115200
>>>>>>>
>>>>>>> I get a connected message but no further progress is done. When i
>>>>>>> press Power button briefly, no activity is shown. I have tried with two
>>>>>>> phones but no success on any. I have checked the connectivity between
>>>>>>> headphone jack and USB serial chip via voltmeter, it is fine as well. Also
>>>>>>> tried by doing Master reset on phone but no use. What can be issue and how
>>>>>>> can i fix it. ?
>>>>>>>
>>>>>>> Kindly ignore any mistakes, i am new to this domain, couldn't find
>>>>>>> much help on google as well :(
>>>>>>>
>>>>>>> [1]
>>>>>>> https://osmocom.org/projects/baseband/wiki/Software_Getting_Started
>>>>>>> https://osmocom.org/projects/baseband/wiki/Osmocon
>>>>>>>
>>>>>>> [2]
>>>>>>> http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software
>>>>>>> -setup.html
>>>>>>>
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Hi Maxim,
> Really cool hack - nice to see it's progressing :)
Thanks!
> Is there some wiki page or readme somewhere which can be
> used as more detailed reference? I'm sure people trying to
> replicate your setup would appreciate it.
Good idea! I'll write a brief description, how to run on SDR
and the road map of the project.
> Also, what are you plans regarding upstreaming osmocom-bb changes?
Well, there are many. Some points from my TODO list:
- Restructurize the project to have a common include directory
for both 'host' and 'target' parts. I don't like the current
problem with 'l1ctl_proto.h': we have several symlinks because
the '$(top_srcdir)/include' is out of include path.
- Extend the L1CTL protocol to have a capability to request
some information about L1 platform, e.g. TX_SUPPORT,
FHSS_SUPPORT, SIM_SUPPORT, PHY_TYPE, etc.
See http://osmocom.org/issues/1461 for details.
- Finish Harald's work, related to getting rid of outdated copy
of libosmocore inside OsmocomBB. Some things are still require
careful testing after migration to newer code.
- Since we have some good updates in Osmcoom gapk, it would be
cool to have audio playback and recording implemented in mobile
application. This way, it will be possible to speak exactly
from PC running the GSM L2 and L3 stack.
- Write a simple (the most things already implemented) tool,
aimed to provide TDMA clock indications from existing BTS.
I'll be happy to see any opinions and additions ;)
With best regards,
Vadim Yanitskiy.
Dear Osmocom community,
I would like to share some good news about development of SDR PHY
for OsmocomBB. In a few words: I was managed to make xCCH and SCH
decoding work, so the ccch_scan application works now!
As already pointed out, I use GNURadio and GR-GSM as a back-end
for signal processing (burst detection and demodulation). Despite
GR-GSM provides some blocks for decoding bursts into L2 packets,
there are some reasons why I don't use them:
- First of all, I would like to keep OsmocomBB compatible with
OsmoTRX, which can only work with raw GSM bursts. Moreover,
one already has TX capability and better stability.
- GR-GSM is only capable to decode xCCH and TCH/F. Other logical
channels (like TCH/H and PDTCH) aren't supported yet.
- GR-GSM uses decoding implementation from OpenBTS project, which
has lower performance / code quality than implementation from
libosmocoding. BTW: Piotr Krysik was working on this issue, and
some work, related to libosmocoding migration, already done, but
not finished for now.
So, we have a simple GR-GSM follow graph, which sends GSM bursts and
some corresponding info (RSSI, frame number, timeslot index) to the
application I am currently working on - trxcon. I have migrated and
a bit modified TDMA scheduler from OsmoBTS project. At the moment,
the application is capable to collect xCCH and SCH bursts, decode
them and send to higher layer applications (L2 & L3) via L1CTL link.
Regarding to L1CTL protocol, trxcon handles the following requests:
- L1CTL_RESET_REQ
- L1CTL_FBSB_REQ
- L1CTL_CCCH_MODE_REQ
- L1CTL_ECHO_REQ
All the results of my work may be found here:
https://github.com/axilirator/gr-gsm/tree/fixeria/trxhttp://git.osmocom.org/osmocom-bb/log/?h=fixeria/sdr_phy
If someone would like to test, one will need:
- GNURadio framework
- gr-osmosdr
- Custom GR-GSM with 'TRX Interface' block (link above)
- fixeria/sdr_phy branch of OsmocomBB (link above)
- SDR device supported by gr-osmosdr
Regarding to the latest requirement, UmTRX board requires external
power source / active cooling, and takes some space on my table, so
I use RTL-SDR. Sounds crazy, but OsmocomBB works on RTL-SDR ;)
One could be used until TX capabilities are implemented.
With best regards,
Vadim Yanitskiy.
Hello FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso
> > If you like, I would be glad to resell you some of the ebay-sourced
> > C139 units in my stash
>
> yes i want . price
Hmm, I haven't really given it a serious thought until now. I can do
$50 USD per phone plus an extra $50 USD for my time to pack the phone(s)
in a box, take the box to the Post Office and fill out their customs
forms, i.e., $100 for one phone, $150 for 2 phones, $200 for 3 phones
etc.
I do need to reiterate though that all of these C139 phones are the
North American version and can only receive 850 and 1900 MHz bands,
*not* 900 or 1800 MHz, thus I don't see how they can be useful to you
in India if your local GSM services are in the bands which these
phones can't receive.
M~
Hi
I needed some information from you, I want to implement a GSM Mobile stack with USRP as RF Frontend. Is it possible to build the DSP part of osmocommbb in a different TI DSP board other than calypso. As it is very difficult to find calypso phones now a days.
BR
Snehasish
Hey guys, first of all I want to express my deep respect for this project,
this is truly amazing project and very well developed.
Second, I'm doing a few studies regarding GSM security (no, I'm not
hacking.) and I need to develop a feature for osmocombb, which is: the
ability to turn the L23 app as a zombie (C unix domain socket) waiting for
instructions (e.g.: connect to the network with predefined parameters
(IMSI), collect RAND, send sms,...).
Is there any documentation or flow regarding the code? It's very hard for a
non C coder to follow the flow... Or is there someone that can help me in
the Architectural level?
Thank you.
> your device, current supports both uplink and downlink rx
Wrong. What do you mean by 'device'?
I can only receive DL bursts for now.
As soon as I integrate TDMA scheduler, it will be possible
to decode raw bursts to L3 packets and forward them higher
layers.
> It can be further be connected to any standard L2/L3
> stack for further processing
What do you mean by 'standard stack'?
Some simple applications like ccch_scan already able
to tune SDR to required ARFCN and to start burst detection.
> Do you have some cfile
What for? You can tune to any of surrounding carriers, and
test the implementation against the real networks. Moreover
you can use RTL-SDR while we don't have TX capabilities.
P.S. Please sign in to the baseband-devel mailing
lists and CC to baseband-devel(a)lists.osmocom.org
because your messages aren't displayed there.
With best regards,
Vadim Yanitskiy.
Hi,
> I want to implement a GSM Mobile stack with USRP as RF Frontend.
Well, I am currently working on that. I don't stick on a specific SDR
device like mentioned one.
> Is it possible to build the DSP part of osmocommbb in a different
> TI DSP board other than calypso.
In case of SDR, DSP part should be done on computer side, like
OsmoTRX does. And some low-level GSM L1 part is already
implemented and could be used by MS implementation too.
If you would like to cooperate me in this direction,
have a look at:
https://github.com/axilirator/osmocom-bb
Right now I am doing some code refactoring, and further
commits will be posted at http://gerrit.osmocom.org/
With best regards,
Vadim Yanitskiy.
Hi,
I am trying to write osmocombb to Motorolla c118 phone by following the
given [1] guide.I have successfully compiled firmware binaries but having
issues while writing them to phone.
I connected motorolla c118 via USB Serial To RS232 TTL to 2.5mm audio jack,
using the given guide [2]
When I run this command
$ dmesg | grep tty
I get the following output
[ 0.000000] console [tty0] enabled
[ 14.946936] usb 3-6: pl2303 converter now attached to ttyUSB0
[ 973.747957] pl2303 ttyUSB0: pl2303 converter now disconnected from
ttyUSB0
[ 1484.595816] usb 3-6: pl2303 converter now attached to ttyUSB0
[ 1845.344494] pl2303 ttyUSB0: pl2303 converter now disconnected from
ttyUSB0
[ 2643.566407] usb 3-6: pl2303 converter now attached to ttyUSB1
And on running this
$ sudo cu -l /dev/ttyUSB1 -s 115200
I get a connected message but no further progress is done. When i press
Power button briefly, no activity is shown. I have tried with two phones
but no success on any. I have checked the connectivity between headphone
jack and USB serial chip via voltmeter, it is fine as well. Also tried by
doing Master reset on phone but no use. What can be issue and how can i fix
it. ?
Kindly ignore any mistakes, i am new to this domain, couldn't find much
help on google as well :(
[1]
https://osmocom.org/projects/baseband/wiki/Software_Getting_Startedhttps://osmocom.org/projects/baseband/wiki/Osmocon
[2]
http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software-setup.html
[2]
Hi Herald
I needed some information from you, I want to implement a GSM Mobile stack with USRP as RF Frontend. Is it possible to build the DSP part of osmocommbb in a different TI DSP board other than calypso. As it is very difficult to find calypso phones now a days.
BR
Snehasish
I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose).
Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development.
-Craig
--------------------------------------------
On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote:
Subject: OsmocomBB compile testing / Re: libosmocore embedded build
To: "André Boddenberg" <dr.blobb(a)gmail.com>
Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com>
Date: Thursday, May 18, 2017, 1:24 PM
Hi Andre and others.
We currently have a series of patches from
Vadim pending in gerrit for
OsmocomBB.
They cannot move ahead, as we have no compile testing /
jenkins job which would give this a +1.
To resolve this, we should
also start to have a jenkins compile testing
job for OsmocomBB. The "host" (PC)
part of the code is built against
regular
libosmocore, just like e.g. openbsc or osmo-bts. That
should be
possible even so far, and it might
make sense to start with that.
Basically you need to:
* git
clone osmocom-bb
* cd src/host/layer23
* regular 'autoreconf -fi &&
./configure && make'
compile-testing the 'embedded'
(firmware) part is not possible easily in
the current master. However, as a second
step, and after the
libosmocore embedded
build has run (and it is installed to
/usr/local/arm-none-eabi), and if you use the
laforge/remove-libosmocore
branch in
OsmocomBB, you should also be able to compile-test the
firmware using
* git clone osmocom-bb
* cd
src/target/firmware && make
There currently is no "make check"
tests for either the host utilities
or the
firmware, and of course we have no clue if the resulting
binaries
will do anything useful on an
actual pone [yet!], but I still think the
two steps above would be very useful to move
ahead, and to unify the
patch
submission/review/verification/approval/merge process in
gerrit
with what we have established for the
network-side projects like OsmoBTS
& co.
Regards,
Harald
--
- 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)
Hi Vadim,
see attachment.
This was my 'test ballon': We now have automatic jenkins build
verification at least for the host part of OsmocomBB. Please re-push
your patch series again into jenkins, so they will get build-verified.
--
- 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)
Dear all,
when we originally moved a lot of generic code from OpenBSC to
libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded'
build of libosmocore, which can use [most of] the library code also in
deeply embedded, OS-less 'bare metal' microcontroller environments.
The ability to build libosmocore this way has been broken for many
years, but I've fixed that in recent libosmocore master. Below command
works for me [tm]:
./configure --prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi \
--enable-embedded \
--disable-shared \
CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"
What we'd need now is:
1) make sure embedded builds continue to work by building libosmocore
for embedded as part of the jenkins setup (using gcc-arm-none-eabi
debian package). Any volunteers?
2) start to use this embedded build from simtrace2 firmware, osmocom-bb
and the upcoming fimrware for the RFDN[1]. So far,
* osmocom-bb uses an old clone of libosmocore,
* simtrace2 is using some copy+pasted fork of some libosmocore files
* rfdn is using some copy+pasted fork of some libosmocore files
The above is no longer required.
3) consider if we can shrink the resource requirements of some
libosmocore parts. One issue coming up are the static buffers in
osmo_hexdump[] or the like. If your total processor RAM is 8k or
16k, then spending 4k on the buffer for hex-dumping is indeed a bit
excessive.
Any help is appreciated, particularly on the jenkins side.
Regards,
Harald
[1] (1:8 splitter-combiner with adjustible step attenuators, part of the
osmo-gsm-tester setup we're building at sysmocom). Code will be
released as soon as the hardware is validated.
--
- 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)
Hi,
> The arm build does not succeed (yet) [2].
>
> Can someone else may have a quick look at log [2] to point me in the
> right direction? Afaics build dependencies are available but the
> compilation itself fails.
As I can see from the console output, build fails because we are
trying to test disabled features, which we haven't compiled.
Fixed by fixeria ;)
https://gerrit.osmocom.org/#/c/2682/1
With best regards,
Vadim Yanitskiy.
> Can someone else may have a
> quick look at log [2] to point me in the
> right direction? Afaics build dependencies are
> available but the
> compilation itself
> fails.
> [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch…
Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the
make of timer_test fails and doesn't log somehow? I"m not sure.
craig@z500:~/libosmocore/tests$ vi timer/timer_test.
timer_test.c timer_test.ok
craig@z500:~/libosmocore/tests$ vi timer/timer_test.c
craig@z500:~/libosmocore/tests$ make check-am
make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test
make[1]: Entering directory '/home/craig/libosmocore/tests'
CC timer/timer_test.o
In file included from timer/timer_test.c:31:0:
../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory
#include <talloc.h>
^
compilation terminated.
Makefile:1336: recipe for target 'timer/timer_test.o' failed
make[1]: *** [timer/timer_test.o] Error 1
make[1]: Leaving directory '/home/craig/libosmocore/tests'
Makefile:1529: recipe for target 'check-am' failed
make: *** [check-am] Error 2
Hi Harald and Craig,
> select.c:27:24: fatal error: sys/select.h: No such file or directory
> #include <sys/select.h>
I have the same issue with:
gcc-arm-none-eabi 4.8.2-14ubuntu1+6
binutils-arm-none-eabi 2.24-2ubuntu2+4
libnewlib-arm-none-eabi 2.1.0-3
> * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
> libosmocore.git (plus an embedded 'malloc' like umm_malloc)
Why do we need this hack (pseudotalloc)?
What if we could cross-compile libtalloc too, and link it against core?
> * have an (optional?) osmocom-bb makefile step to git clone + configure
> + make install libosmocore
Great idea! What about to have libosmocore as a git submodule inside
OsmocomBB (like OpenCL headers in hashcat)?
Also, I think it would be good to make libosmocore more modular,
because it could allow us to create more flexible builds (e.g. to compile
only what we need, not a whole library). This makes sense in case of
low RAM / ROM embedded systems. What do you think?
With best regards,
Vadim Yanitskiy.
I got around this error by adding a #if (!EMBEDDED) around all of select.c and moving the #include "../config.h" to the top.
diff --git a/src/select.c b/src/select.c
index 8ed7f1b..e51e50a 100644
--- a/src/select.c
+++ b/src/select.c
@@ -20,6 +20,8 @@
* MA 02110-1301, USA.
*/
+#include "../config.h"
+#if (!EMBEDDED)
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
@@ -30,7 +32,6 @@
#include <osmocom/core/linuxlist.h>
#include <osmocom/core/timer.h>
-#include "../config.h"
#ifdef HAVE_SYS_SELECT_H
@@ -235,3 +236,4 @@ struct osmo_fd *osmo_fd_get_by_fd(int fd)
/*! @} */
#endif /* _HAVE_SYS_SELECT_H */
+#endif /* !EMBEDDED */
After that the next error in building is related to talloc.
make[3]: Entering directory '/home/craig/libosmocore/src'
CC select.lo
CC utils.lo
In file included from ../include/osmocom/core/utils.h:4:0,
from utils.c:30:
../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory
#include <talloc.h>
I didn't see the laforge/pseudotalloc branch. Did you forget to push it? How is this dealt with currently in osmocom-bb for embedded?
Thanks,
Craig