Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
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 All!
That's true, I managed to run U-Boot on MT6235, but linux kernel is
not fully functional yet (it's fresh stuff as I managed to ran it on
Tuesday and then I was off to conference).
For MT6235 development I chose Sciphone G2, which is pretty cheap.
After some time I managed to download code to SRAM (just 64KB) using
MTK's FlashTool.
MTK FlashTool communicates over UART directly with MT6235 bootloader
and sends its own chunk of code (about 58KB) which is executed in SRAM
and communicates with FlashTool.
I found on pudn.com some pack to customize code loaded by FlashTool,
thanks to which I could download my own code to SRAM (without JTAG).
The problem was that it had to be linked with some security libraries
which occupied about 56KB and not much memory left for my own code.
Then I decided to try find JTAG pins to get all control on MT6235.
That took me sometime, but finally I succeeded.
The other bigger issue was initializing DRAM controller to be able to
download bigger code (linux kernel + uboot) to external RAM. In
sciphone there is problem that all interesting chips are under metal
shield which is pretty havily soldered. In this case I couldn't read
what kind of RAM memory is mounted without destroying the board (I
don't have such soldering machine which could unsolder so big metal
shield). Thanks to JTAG I could attach to target and then dump DRAM
controller registers from processor running MTK's software, but
setting these values after processor start and configuration of PLL
didn't work.
I decided to disassemble bootloader which could show me how DRAM
controller is initialized and how code fron NAND is loaded (to be able
to flash U-Boot and kernel to NAND so MT6235 will start my code
automatically and I will not have to use JTAG). Currently I have
knowledge how internal MT6235 bootloader is loading code from memory
during startup and I also extracted procedure of DRAM controller
initialization. Thanks to that I'm able to run U-Boot from the very
begining of processor startup.
The problem is that I have just one piece of Sciphone G2 and I don't
want to flash it yet to not break existing code in it. Thanks to
running device I'm able to attach with JTAG and check how peripherals
are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm
not 100% sure if I will flash it back, phone will startup. That's why
I bought second piece of Sciphone G2 and should receive it today or on
Tuesday (this Monday is holiday in Poland). In this case I'll flash
U-Boot to NAND and try to make it working. Then we could load the rest
of code from U-Boot (to RAM or NAND over serial).
You can see how my setup looks on attached picture.
The good thing about it is that the same bootloader is used in MT622x,
so it should be fairly easy to do the same on phones based on that
SoCs (but unfortuantely it's just ARM7).
If it comes to code, of course I can share it on "git.osmocom.org".
Currently it's just basic port of U-Boot and not much for linux
kernel, but I'm working on this now so I'll push it when it'll be
ready.
Currently I'm working on driver for NAND memory for U-Boot, so we
could flash linux kernel. When that will be ready I'll push the code.
Then I'll switch to linux kernel and when it'll be functional I also
push the code. At this stage you will not need to have JTAG and you
could load the code over serial in U-Boot.
If it comes to GSM I didn't work with it before. I actualy worked 6
months in L2/3 team for LTE (on RRC) but it's different story.
That could be really outstanding thing if we could run first phone
ever with whole code open (from BB up to APP).
BR,
Marcin
Hi guys,
I dunno if that is the right place for my concern about building the
osmocomBB source. Here is what I already have done:
- downloading the sources for osmocomBB and GNU toolchain for ARM,
- setting the PATH for the arm-elf-* executables,
- calling make in the src directory.
Now, this appears as response of the make command in the terminal:
cd shared/libosmocore/build-host && ../configure
configure: error: cannot find install-sh, install.sh, or shtool in ".."
"../.." "../../.."
make: *** [shared/libosmocore/build-host/Makefile] Error 1.
If you need details about my system, you can look at the following
snippet from the config.log file:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libosmocore configure UNKNOWN, which was
generated by GNU Autoconf 2.65. Invocation command line was
$ ../configure
## --------- ##
## Platform. ##
## --------- ##
hostname = ubuntu-stefan
uname -m = x86_64
uname -r = 2.6.32-24-generic
uname -s = Linux
uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2032: error: cannot find install-sh, install.sh, or shtool in
".." "../.." "../../..".
So, I would be very glad, if someone could give me a hint to solve the
problem. Thank you in advance.
Regards,
begy
Hi,
I could not resist buying a C116 for 15 euro, so I compiled osmocombb
and connected a 3.3V serial cable.
Of course the C116 was not in the supported list, but I was hoping it
would work as it seems that it is very similar to the C115.
Here is my load attempt: (used -m c123 ) but there's no loading of the image.
I am not using TX mode, also I don't have a SIM installed.
Anything I can try to get it working?
./osmocon -p /dev/ttyS0 -m c123xor
../../target/firmware/board/compal_e88/loader.compalram.bin
got 1 bytes from modem, data looks like: 00 .
got 2 bytes from modem, data looks like: 00 81 ..
got 4 bytes from modem, data looks like: 1b f6 02 00 ....
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=16788, hdr_len=4, dnload_le n=16795
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6c l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
Regards,
Henk
Hello techies!
I am new to the list and I acquired a c139. I'd like to buy a rs232/jack
2,5mm named t191 flash (and not unlock) cable. They look 100% the same (even
stickers). Is this important? I understand that I have also to use a
rs232/usb adapter. The one I have (U232P9 with link/tx/rx leds) gives +/-9,4
v. So my concern is to not fry the Moto..Any advise welcome.
Cheers.
hi all,
About voice,I have one question.
In the latest git code, when I use bb to call other phone, it will product a
file voice.raw.
How I can play the voice.raw?
which kind of format? 16bit or 8 bit pcm?16khz and 8khz?LSE or MSE?
In fact i used the cooledit to play it, both 16khz and 8khz, it has only
noise.
Other question, I want to input voice from pc that run BB, then the voice
can be sent by C123.
But I found the voice that be sent by C123 is C123 input voice.
Can we realize the idea?
Best Regards
Shrek W
Hi all, my name is Jose Pereira, and i'm very interested in helping you with
some code! I've wrote the buzzer driver for calypso, not so sure if will
help you of anything, but was just for experimenting :)
Anyway, i send the patch in attachement. The interface can be simply
#include <calypso/buzzer.h>
buzzer_mode_pwt(1);
buzzer_volume(40);
buzzer_note(NOTE(NOTE_E,OCTAVE_5));
Please let me know what do you think of the code, and in what way i can
further help.
Best regards,
--
José Pereira
http://onaips.blogspot.com
Hi All!
At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe,
one of the attendees (Marcin, see Cc) came to me after the talk and told me he
had recently done a u-boot and Linux kernel port to the MT6235 (that's the
ARM926 based chipsets found in the touchscreen MTK phones).
He said he has no understanding of GSM or the existing MTK firmware, but is
interested in working together with us to try to make the GSM part work.
I think that chipset is very intesting, as we could implement the layer1
inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and
layer3 implementations as userspace processes on the Linux system, together
with the user interface.
The performance of those devices should be somewhere between the Openmoko GTA01
and GTA02, and the GSM stack is certainly not going to eat away a lot of the
CPU either.
I have asked Marcin to write mail to the OsmocomBB mailing list on where we can
find the code. He has so far downloaded the code using JTAG. Combining his
code with our ramloader might remove that JTAG dependency...
Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a
separate trac installation for your mtk-linux work, pleaes let me know, I'd be
happy to host that.
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)
Andreas said he is OK with applying them, so I will do that.
>
> OK :)
> However, if I read your code correctly, it still seems to me that there is
> a fixed compile time decision if gpsd or built-in gps support is to be
> used.
>
> I think it would be better to keep it a runtime decision, i.e.
>
> 1) if gpsd headers/library available during compilation,
> build support for _both_ gpsd and built-in gps into the program,
> 2) if they are not available, only include the built-in gps support.
>
> That's easy to do. I can maintain the original gps interface, so old code
doesn't need to be fixed, and choose the support to use from an internal
state.
> The decision which method to use should be a config file option. Please
> make
> sure that a config file configured for built-in gps support will work with
> both
> versions of the program.
>
> A config file requesting the use of gpsd support should make the program
> abort if it was compiled without gpsd support included.
>
> Not sure to agree. Execs from layer23/misc don't rely on config files.
Probably that's due to the low number of switches used. I think that, even
if cell_log options are increased, we can still use cmd switches. Do you
agree?
Ciao
Dario.
Hi all,
I would like to propose moving the config file into something like ~/.osmocom/
and not put it in a system wide directory. The path in /etc/ is the only
part of OsmocomBB that requires root privileges, and I don't really think
that in a case of multiple users you would want to e.g. share stuff like
the IMSI / Ki anyway.
What do you think?
--
- 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)
the GSM bts Features =GSM phone
we can use usb interface phone to do a same Features GSM bts
we can use motorola c375 c450 c550 and MTK chip phone all use interface phone
this is a cheap Program
can you tell me the osmocom feature isnt same we can use openbts software Connection the phone
Hello,
I have the problem connecting to the phone with osmocom tool. For what I
have read on this list trying to run helloworld example app should work, and
if there are problems connecting they stem from the cable/adapter being low
quality.
For now I have tried with three different usb-rs232 adapters (2 on
winchiphead ch341 chip then I switched to prolific PL-2303 chip) and with 3
different phones (1xC155 and 2xC121) but in any of those configs I am not
able to successfully run helloworld - it doesn't receive 'prompt' message as
written in wiki - CompalRamLoader. Instead for C121 I always get:
./osmocon -p /dev/ttyUSB0 -m c123
../../target/firmware/board/compal_e88/hello_world.compalram.bin
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 7e ~
got 5 bytes from modem, data looks like: 82 bf 7d fd 7f ..}..
got 1 bytes from modem, data looks like: 00 .
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: 02 .
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 tried to stty different port speeds but still only got above sequence.
Have you got any suggestion what could be the problem or what direction
should I follow to get it working?
Hello.
I'm trying to send a location update message using IMSI, but I never receive
a reply from the BSC (Authentication request, identity request or location
reject).
If I change the location update identity using a TMSI, then I receive an
Authentication Request or an Identity Request.
Could be the IMSI format worng? The used IMSI is valid. I copy the string
containing this one into the subscriber imsi field.
Should I use an encoding function?
I hope the issue is clear.
Thanks in advance for support.
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/IMSI-format-tp2576369p2576369.ht…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi all,
I am running some tests/experiments with the burst_ind branch. I want to be able
to only follow the immediate assignments for my TMSI as it is difficult to
verify that the bursts are indeed my traffic. However, I suspect this is not
possible using only downlink traffic as without the channel request from the MS
I cannot match the resulting IA? I would need to capture uplink too?
I would be grateful if someone could confirm if this is the case or if there is
a way around this issue?
Many thanks,
Matt.
Hi guys
I think that many of you know opencellid. Did you find its info precise?
When querying for cells of my area, I get a positioning that is far far
away from the right one. Are there other areas where their positioning
is better?
Dario.
Hi all,
Does anyone have any suggestions with regard to models of phone in which it is
easy to view the current Kc? I have a Motorola C115, Nokia 3310/6630, Android
Desire, iPhone etc. I can get every everything from the in built field test
modes, however I really want to get the current session key so that I can
verify/analyse my captured bursts.
Thanks,
Matt.
Hi,
the phone does not seem to be involved in this topic. It's only about the
SIM.
And you can't flash a sim like a baseband. That would be too easy.
Sebastien
On Tue, Feb 22, 2011 at 3:28 PM, Marius Cirsta <mforce2(a)gmail.com> wrote:
> A nicer fix would be to flash it with some open source firmware :).
> That would be cool and I guess it's what this project is all about.
>
> On Tue, Feb 22, 2011 at 5:24 AM, Harald Welte <laforge(a)gnumonks.org>
> wrote:
> > On 02/20/2011 02:07 AM, Scott Weisman wrote:
> >>
> >> I apologize for this in advance. I figure the collective GSM knowledge
> >> here might be able to help me.
> >
> > Well, I think it is interesting from a 'scientific' point of view, i.e.
> > understanding how such mechanism is implemented.
> >
> >> I have a SIM card that can only be used on one phone. The phone itself
> is
> >> unlocked. But the SIM won't work on any other phone. Does anyone know
> >> anything about this or how to unlock a SIM to work on any phone?
> >
> > I think the first step is to trace what is happening between phone and
> sim
> > card, possibly by using osmocom simtrace.
> >
> > Once you have a trace, you can look at the messages and try to identify
> the
> > mechanism the SIM uses to identify the phone. After that, you could
> > possibly implement a small program for a proxy SIM like bladox or
> RebelSIM
> > which patches the messages to make the SIM card happy.
> >
> > All in all not an easy undertaking, but it can definitely be solved.
> >
> > Regards,
> > Harald
> >
> >
>
>
hi dario,
i just tried to compile master and your patch. (heaving gpsd installed)
here are some problems:
CC gps.o
gps.c:41: error: 'gps' redeclared as different kind of symbol
/usr/include/gps.h:127: error: previous definition of 'gps' was here
gps.c: In function 'osmo_gpsd_cb':
gps.c:73: warning: implicit declaration of function 'gps_waiting'
gps.c: In function 'osmo_gpsd_open':
gps.c:123: warning: implicit declaration of function 'gps_stream'
gps.c:123: error: 'WATCH_ENABLE' undeclared (first use in this function)
gps.c:123: error: (Each undeclared identifier is reported only once
gps.c:123: error: for each function it appears in.)
1. the symbol "gps" is used as structure instance for struct osmo_gps.
it is also used in an enum declaration at /usr/include/gps.h:
...
enum {gps, glonass, unknown} system;
...
2. the declarations 'gps_waiting', 'gps_stream', 'WATCH_ENABLE' are not
defined at gps.h
this is maybe one reason why i failed to write gpsd support. symbols in
the howtos and examples were missing. here is the latest version i got
from the gentoo repository:
* sci-geosciences/gpsd
Latest version available: 2.32
Latest version installed: 2.32
Size of files: 603 kB
Homepage: http://gpsd.berlios.de/
Description: GPS daemon and library to support USB/serial GPS
devices and various GPS/mapping clients.
License: BSD
any ideas?
andreas
> Then try to find what's the minimum version (see api changes in the
> gpsd history I guess) and make sure in the configure to check it.
i found it at http://gpsd.berlios.de/. not both apis must be supported,
at least check for version 2.90 or later, to decide to use gpsd.
I apologize for this in advance. I figure the collective GSM knowledge here
might be able to help me.
I have a SIM card that can only be used on one phone. The phone itself is
unlocked. But the SIM won't work on any other phone. Does anyone know
anything about this or how to unlock a SIM to work on any phone?
Yes, I have tried searching, but because PHONE unlocking is such a common
theme, this just passes through the cracks.
Thanks,
Scott
> I have written the new code that supports gps selection at runtime
> through cmdline switches. Send me any comment you have :).
looks good to me. if you have access to git, just commit it, else send
me all patches (or combined as one patch) and i will commit them.
Hi,
for anyone also playing with the Pirelli phone, I got mine running on
a live network. Here's my recipe:
- change header files for Pirelli (see wiki)
- compile source
- setup usb
modprobe -v cp210x
echo "0489 e003" > /sys/bus/usb-serial/drivers/cp210x/new_id
- attach phone without battery on USB
- from src run
./host/osmocon/osmocon -p /dev/ttyUSB0 -m romload ./target/firmware/board/pirelli_dpl10/layer1.highram.bin
now the tricky part: sometimes the romloader succeeds when you insert the battery, but most
times you have to power on the phone and then power off (now the bootloader uploads the .bin)
- run mobile (you need to touch an empty osmocom.cfg)
./host/layer23/src/mobile/mobile -i 127.0.0.1
telnet localhost 4247
- play via telnet - you can't break anything
now the real fun, enable transmitting
- enable transmitter (don't forget to "make clean") in Makefile
- select your local channel (I used an other phones cellid and looked up the channel)
stick <number>
- use random IMEI (000.. didn't work on my network)
imei-random 15
- use test sim (if you know your IMSI/KI - I could't get the SIM working)
test-sim
imsi 22801<secret>
ki comp128 <secret>
If all works, you'll find in your logfile something like:
TMSI 0x25f0ec42 (636546114) assigned
if your keys are wrong, you'll see something like:
gsm48_mm.c:1581 AUTHENTICATION REJECT
I wasn't able to make any real calls from the mobile to any landline
but at least signalling in the other direction worked:
telnet showed: Incoming call (from +49711xxxxx)
Have fun
Leif
Hello,
I was wondering if there is a soft GSM client....the sort you could run like a sip client
on your laptop to connect to the GSM/UMTS network just like UMA/GAN phones do via Up
interface.
Regards,
Abdul Hakeem
Hi list,
After some break finally I managed to describe and commit all changes made to MT6235 Linux port during last one and the half month.
Currently I got full Angstrom Linux distribution running with UI.
Now you can run everything what I'm writing below without changing Sciphone's original firmware. Just use osmocon to load U-Boot to RAM and SD card which has rootfs (with Linux kernel placed in /boot/uImage).
For the beginning I chose OPIE, which runs on both versions of Sciphone - with 32MB and 64MB of RAM.
OPIE is based on Qtopia which is lightweight and runs pretty fast on MT6235.
When you run OPIE on Sciphone G2 it works as full blown PDA. In OPIE there is no telephony support.
I also ran X window server with blackbox and matchbox window managers.
It runs fine with this difference that sometimes I got oops messages concerning memory on phones with 32MB of RAM . I'll investigate it in the future.
Next step is running SHR and Android (probably only on 64MB versions).
Android will be working very slow, but from marketing point of view "Android" is magic word so I guess it'll bring more interest into project.
For building Linux distributions I chose OpenEmbedded where you can build a lot of Linux variations.
To be able to do this I prepared patch which adds Sciphone G2 target and adds U-Boot and Linux kernel repositories from OsmocomBB project.
All details regarding OE are described on wiki:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
With above patches you're able now to build Linux distribution with any configuration by yourself (Angtrom, SHR, QTE, OPIE, GPE, etc.).
Video presenting how Angstrom Linux with OPIE is running on Sciphone G2 is placed under following link:
http://www.youtube.com/watch?v=-_guRruQi0I
As you can see, there is already new OsmocomBB logo. When it's on white background, it means that U-Boot is running, when it's on black background it menas that Linux is starting up.
On above video I used phone (32MB of RAM) which has only U-Boot flashed, everything else is running from SD card.
Unfortunatelly OPIE has a lot of elements on boarders of screen (scrolling, application close, etc.) and Sciphone's touchscreen has pretty bad quality and it doesn't work well. You have to be patient while operating it. In the middle of screen it works pretty well. I'm going to improve touchscreen driver, so hopefully it'll work better.
I prepared ready to load images from above presentation for people who want to try it out without building:
http://downloads.qi-hardware.com/people/marcin/sciphone_g2_mt6235/images/
Below is short status what's going on now in Linux work.
Peripherals which are already running under Linux:
1) GPIO
2) clocks
3) timers
4) SD card
5) LCD frame buffer
6) touch screen
7) keypad
8) NAND - not yet finished under Linux as I had no motivation to finish it (it fully runs under U-Boot)
9) RTC - not yet integrated
10) U-Boot has been rebased to newest version and commit history was cleaned - preparations for mainlining of Sciphone G2 port
Topics on which we're working now:
1) rebase Sicphone's kernel to newest version
2) USB
3) Audio - needs to know how DSP is working
4) Android porting
I hope above software will also run on your devices.
BR,
Marcin
Hi all
here I am with the first patch to support gpsd. The new code is used
only if libgps is found, otherwise old code is used. There is an issue I
had to bypass when integrating old code: the osmocom gps_* funcs have
identical names to the libgps api :(. So I had to rename the osmocom gps
functions to osmo_gps_*. Unfortunately when using logic names for
functions sometimes it creates collisions with other code :). Hope this
doesn't create new issues.
Tell me if you think it can be considered good from coding approach and
if it works :).
Cheers
Dario.
On Tue, Feb 15, 2011 at 05:37:48PM +0100, Dario Lombardo wrote:
> Hi guys
> Any news this side? Are patches ok? Are you planning to merge them? If
not,
> tell me what's wrong so I can change it.
hi dario,
sorry, but i did not follow this list the last days. just apply the
patch. it seems ok to me.
best regards,
andreas
hi, its probably best if you post this on the public mailing list, not
directly to me,
as i am not that involved with the project (this reply is CC to the
baseband-devel
btw. - so that you dont have to remail it, and everything is in context :)).
so long!
azet
On Tue, Feb 15, 2011 at 9:45 PM, Brian Wiborg <baccenfutter(a)c-base.org> wrote:
> On 02/14/2011 08:05 AM, Aaron Zauner wrote:
>>
>> hi,
>>
>> as there has been much spam ongoing and countless discussions of
>> build-problems from users
>> who didnt read the (not quite so good) documentation. i am suggesting a
>> new mailing list for new-
>> comers, buildproblems and so on. i am a bit frustrated over reading
>> countless threads that have
>> nothing to do with actual development.
>>
>> just a suggestion.
>>
>> so long
>> azet
>> --
>> "I have no certainties, at most probabilities." -- Renato Caccioppoli
>
> hi aaron,
>
> to make it short:
> have you folks considered just moving the noise to irc? I'd be really
> interested maintaining and developing such a #channel and help the community
> collaboratively grow. who would this best be discussed with?
>
> best regards
> brian
>
--
"I have no certainties, at most probabilities." -- Renato Caccioppoli
hi,
as there has been much spam ongoing and countless discussions of
build-problems from users
who didnt read the (not quite so good) documentation. i am suggesting a new
mailing list for new-
comers, buildproblems and so on. i am a bit frustrated over reading
countless threads that have
nothing to do with actual development.
just a suggestion.
so long
azet
--
"I have no certainties, at most probabilities." -- Renato Caccioppoli
Hi
Does anyone have any info on Mediatek MT6516 ? I'd like to take a look
at a datasheet if possible and I also know Android had been ported to
it. Any chance of some open source code being released by Mediatek ?
Thanks.
sounds quite interesting, but is it even possible to run osmocombb natively
without host and target program (thus with connection to a pc/notebook)?
azet
--
"I have no certainties, at most probabilities." -- Renato Caccioppoli
Hi all,
Sorry for the delay, here are the sources for glocation program I made which uses Google API to get your location.
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
Hi Sylvain, hi Steve, hi list!
I did some kind of backport of Pirelli DP-L10 support for the
burst_ind branch, patch attached.
Remember that after applying you still have to swap the UARTs
as mentioned in the wiki to maintain compatibility with the
usual configuration in compal phones.
The convenient thing with using the Pirelli with burst_ind is
that it works out-of-the-box at high serial speed using its
standard usb cable (without 2.5 jack to serial to ftdi-usb
constructions).
But there is one issue I came across with layer23, after a
short time of normal operation when returning from DCH to CCH
it just gets stuck.
The FBSB request returns 255 as result so I guess the fw was
not able to resyncronize. When a new request is made by
restarting layer23, it works again for some time.
Perhaps it has something to do with the used calibration
values like SYSTEM_INHERENT_GAIN for the gain control etc.
which could be different with the Pirelli layout?
BTW, Sylvain, will there be an integration of burst_ind
functionality into the master branch at some time, do you
have some plan for this?
Regards,
Mad
Hello,
I'm newbie to osmocomm and GSM too....I'm studying the protocol and the
source code...but I have many doubts...the first one is the following:
1. Which are the routines handling FCCH and SCH in osmocom source code?
2. When I load layer1 firmware and load mobile app, FCCH and SCH are
automatically handled by this application?
Sorry if my questions are stupid for you, but it's a litlle bit complicate
moving in the code, above all for a newbie.
Thanks in advance.
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/FCCH-and-SCH-tp2363201p2363201.h…
Sent from the baseband-devel mailing list archive at Nabble.com.
On Tue, Feb 08, 2011 at 09:08:40AM +0100, Rade Girel wrote:
> Thats true, but i for myself hope that one day the layer23 code is
> moved into the phone. At that time i would really like to have a
> tested, accepted in short usable UI on th osmocomBB compal phones.
I think we can start by moving the stuff step by step into the phone,
if anyone wants to work on this, it would be much appreciated.
Layer2 (LAPDm) should be relatively simple, but starting from RR/MM/CC
and the cell reselection I expect some more difficulties...
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)