Status of bug #1024 (periodic signal lost and re-registration)
spaar at openmoko.org
Mon Dec 22 18:13:55 CET 2008
> I understand the difficult in reproducing #1024. I can reproduce it
> very easily (San Jose, CA, USA, Pleasanton, CA, USA: (Providers:
> T-mobile, AT&T)) . How much would an RF dump help? I mean, I can give
> you SSH access to Freerunner, if you'd like. What can the community do
> to help you?
One of the interesting questions is to find out if there is a "pattern"
for #1024. Do you
experience it all the time or only in certain areas ? And does #1024
occur all the time
or only sometimes, maybe depending on temperature or battery charge
level ? Do you
know other Freerunner users in your area and do they also experience
In the moment I don't think that other traces from the phone would give
information. We have to find out why this happens what we can see in the
I don't expect that RF dumps would currently give us more information,
as it seems
right now, the problem probably comes from the phone and not from some
or disturbed RF signals from the basestation. This would be different if
also loose the signal, but as it seems, only the OM phones seem to be
traces might help at some later point (see below).
The best would be to have a clear description how to reproduce #1024.
like "cool the phone down in the refrigerator and than you experience
simplified example of course). Then we could try to solve the problem
this can still be lots of effort). In the moment we are somehow "poking
in the dark",
we could of course try to change something here and there and see if
this has some
influence but this would require lots of effort, not just on our side,
because we also
need someone to try it out and report about the results as long we can't
> For possible cheap ways to gather more data:
> -If you have a firmware that can save out the RF. We could deploy it
> on our Freerunners that are exhibiting the problem, and send up the rf
> save out. This might be very naive, as I don't really understand how
> the Calypso chip works. These guys seem to be working on something
> similar: http://wiki.thc.org/gsm/opentsm
Yes, I know this project very well ;-) The problem is that the software
of this phone is about
two years older than the software OM uses. Additionally this older
version does not yet
support the "Deep Sleep" mode so it can not be used as a reference to
check what is
going on during "Deep Sleep".
The other problem is the DSP inside the Calypso. It does the basic RF
stuff. However you
don't find a lot of documentation about what this DSP does. Its has its
code in ROM, only
a few binary-only patches are applied to the ROM code when the Calypso
starts up. The
project you reference above also does not have the source code for the
there is an older ROM version in those phones.
I will try to find out a bit more about this "error flag" which is set
when #1024 occurs,
but the problem here is the missing documentation, source code and the
its ROM code. However its not impossible to find out some more details,
can take a _lot_ of time. And life would be easier if we would know how
> -Get a USRP(2), and the proper transceiver boards. We can do the
> captures. Obviously there would be a lot of noise, so we'd have to
> figure out a way to get this out. These devices are expensive, so I'm
> not volunteering to purchase one, but I would split the cost with a
> few other Freerunner owners, and give OM access to the USRP, and a
> Freerunner in its proximity remotely.
I think currently the status of making GSM captures with an USRP is not
However there is a lot of work going on and I expect some progress from
CCC congress in Berlin where also several people related to GSM projects
(http://events.ccc.de/congress/2008/wiki/GSM). I hope to have a better
if an USRP could help to find out more about #1024 after the congress,
can decide if it makes sense to capture GSM traffic when bug #1024
_maybe_ even play it back to reproduce #1024 (not sure if I am too
here, and if the OpenBTS project could help, but lets wait till the
congress is over).
And of course recording and playing back only makes sense if we know that
its the RF signal which causes #1024.
> Dieter, I may be babbling, feel free to call me out if I am, but will
> any of this help?
Your ideas and thought are very welcome. The USRP is probably something
look closer, but right now I think the software side for GSM capturing
is not yet that
perfect. And currently we don't know for sure if it is really some
parameter of the
basestation RF signal which triggers #1024. It could be the combination
of the signal
from the serving cell basestation and its neighbor cells, than it will
be _really_ difficult
and probably nearly impossible to capture the RF signals and play it
back, even with
more than one USRP.
More information about the hardware