baseband-devel

baseband-devel@lists.osmocom.org

1981 discussions

by f12.sebastian

Hi I am trying to test osmocom-bb/fixeria-Trx. After configuring test-sim the functions for receiver side like the " network selection mode " " select ARFCN" do work. But how to test or configure " Early Classmark Sending" for varying set of encryption (A5/1,2,3,4...). Regards. --

7 years, 7 months

Re: Classmark Testing

by Vadim Yanitskiy

Hi Max, This work is a part of "GSM and GPRS Security Using OsmocomBB" thesis written by Francois Ponsgen and was published a quite time ago. Moreover, I already have the changes in my local repo, which is mostly used for research purposes. I can push them, if it's really required. BTW: if I remember correctly, this work was done in NTNU ;) With best regards, Vadim Yanitskiy.

7 years, 7 months

[PATCH] mtk: fix firmware makefile to work with current osmocom-bb makefile system

by Craig Comstock

--- src/target/firmware/Makefile.mtk | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/target/firmware/Makefile.mtk b/src/target/firmware/Makefile.mtk index 30fa2fcf..927e31a0 100644 --- a/src/target/firmware/Makefile.mtk +++ b/src/target/firmware/Makefile.mtk @@ -4,14 +4,16 @@ BOARDS?=mt62xx # List of all applications (meant to be overridden on command line) APPLICATIONS?=loader_mtk -mtkram_LDS=board/mediatek/ram.lds -mtkram_OBJS=board/mediatek/start.ram.o +APP_loader_mtk_ENVIRONMENTS=mtkram + +ENV_mtkram_LDS=board/mediatek/ram.lds +ENV_mtkram_OBJS=board/mediatek/start.ram.o mtk_COMMON_OBJS=board/mediatek/uart.o # Mediatek MT62xx -mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o -mt62xx_ENVIRONMENTS=mtkram +BOARD_mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o +BOARD_mt62xx_ENVIRONMENTS=mtkram # Global include path INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include -- 2.15.0

7 years, 7 months

GAPK status update

by Vadim Yanitskiy

Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy.

7 years, 7 months

Osmocon failed to flash

by felangga＠gmail.com

Hello, I'm newbie and want to learn about osmocombb. I already compiled all of the programs, but when I try to upload helloworld program, it stuck on this error $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/ compal_e88/hello_world.compalram.bin -c 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 2 bytes from modem, data looks like: 82 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 . I don't know if it hardware problem, or software problem. When I try to debug using putty to listen to /dev/ttyUSB0 there is no fmttool erro just like this article said http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software-setup.html Regards.

7 years, 7 months

State of primitives and lua bindings

by Holger Freyther

Hey, I think I have the minimal patchset to add primitives and lua bindings to have useful functionality and know what is good/bad with it and extend/iterate it from here. I would like to share the state and what's next. On the higher level we have: * Primitive for timers * Primitives OP_IND for started/shutdown handling * Primitives OP_IND for SMS status and RX SMS * Primitives OP_IND for Mobility Management state changes Next steps: * Pack MNCC and enable/handle voice calls as well to do call control. What needs to change in future iterations: * SMS, MM, started/shutdown indications should be async. Especially for MM handling that will do further state changes from within the new_mm_state. So if we enable/disable the MS within this callback we ask for trouble. * The lua scripting code is calling some routines directly. E.g. for a "simple" SMS sending routine, to query state. This should probably be converted to primitives as well. But that can be done while keeping the lua API (e.g. with continuations or cache the MS status). * Finish the OsmocomBB manual documentation for the API * Bikeshed. Number vs. Bool... ;) Bugs found by scripting: * I found an ASAN issue in mobile (fix pending) * Noticed paging with outdated TMSI on NITB * Trying to encode an alphabetic phone number causes issue in libosmocore (bug report pending) cheers holger Examples: # Print through logging framework print("Hello from Lua"); log_notice("Notice from lua"); log_debug("Debug from Lua"); log_error("Error from Lua"); log_fatal("Fatal from Lua"); # Start a timer... and cancel it. Notice the ':' local timer = osmo.timeout(1000, function() print("After timeout!!!") end) timer:cancel() # Access a osmo.ms() singleton table/object print("MS", type(osmo.ms())); osmo.ms():imsi() osmo.ms():imei() osmo.ms():shutdown_state() osmo.ms():started() osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) osmo.ms():start() osmo.ms():shutdown(force) # Callbacks... function ms_started_cb(started) end function ms_shutdown_cb(old_state, new_state) end function sms_cb(sms, cause, valid) for i, v in pairs(sms) do print(i, v) end end function mm_cb(new_state, new_substate, old_substate) if new_state == 19 and new_substate == 1 then osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) end end local cbs = { Started=ms_started_cb, Shutdown=ms_shutdown_cb, Sms=sms_cb, Mm=mm_cb } osmo.ms():register(cbs)

7 years, 7 months

Re: OsmocomBB layer1 with FreeCalypso changes

by Vadim Yanitskiy

Hi Mychaela, Great work! I just had a quick look and did some tests. Do you agree if I would merge your changes to the mainstream under GNU GPL version 2 license, keeping you as the author? With best regards, Vadim Yanitskiy.

7 years, 7 months

primitives without msgb

by Holger Freyther

Hi, while I am adding scripting support to the mobile application I tried using a primitive interface between the scripting implementation and the mobile application. On new indications a callback in the primitive interface user will be invoked and there is a generic submit function that will dispatch (switch/case) over the primitive and call the right internal functions. To prototype this I have implemented "timer" support, SMS and the started/shutdown handling through primitives. The neat thing about this approach is that I don't tie a specific scripting solution into the code, the indications are generic enough to be useful in multiple contexts, the submit/dispatch is about high level operations ("send SMS", "switch device off") that map to other programming languages as well. E.g. it is easy to imagine that one writes a TCP/IP adapter to send these primitives to another process/application. The controversial part is that this code is not using a msgb. Normally the primitive header is inside a msgb and then more or less points to itself. But in the scripting layer case the "timer", "new sms", "network selection" are already fully parsed objects (or where never parsed from a network representation) so are normally not located in a msgb in any form. One option is not to bother and deal with the primitive header just being embedded in another structure. The concept of request/response/indication is bigger than network messages. The other is to create a dummy msgb to obey the interface and follow the existing users but I am not sure what we would gain. For XYZ->internal we can use direct function calls and avoid the indirection of the primitives and for indications either call directly into the scripting code or create a script_indications struct and put it into the struct osmocom_ms. Only downside that doing RPC requires more work? So far I only forsee a single "script_indications" callback. comments? opinions? holger

7 years, 7 months

GSM850 downlink band SAW filter

by Mychaela Falconia

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

7 years, 7 months

OsmocomBB layer1 with FreeCalypso changes

by Mychaela Falconia

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

7 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel