Status of bug #1024 (periodic signal lost and re-registration)

[Dieter Spaar]

Hello Sargun,

> 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 
#1024 ?

In the moment I don't think that other traces from the phone would give 
us more
information. We have to find out why this happens what we can see in the 
traces.
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 
faulty
or disturbed RF signals from the basestation. This would be different if 
other phones
also loose the signal, but as it seems, only the OM phones seem to be 
affected. RF
traces might help at some later point (see below).

The best would be to have a clear description how to reproduce #1024. 
E.g. something
like "cool the phone down in the refrigerator and than you experience 
#1024" (very
simplified example of course). Then we could try to solve the problem 
(of course
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 
reproduce
#1024.

> 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 
DSP, additionally
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 
DSP with
its ROM code. However its not impossible to find out some more details, 
but this
can take a _lot_ of time. And life would be easier if we would know how 
to reproduce
#1024 :-)

> -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 
that perfect.
However there is a lot of work going on and I expect some progress from 
the upcoming
CCC congress in Berlin where also several people related to GSM projects 
will meet
(http://events.ccc.de/congress/2008/wiki/GSM). I hope to have a better 
understanding
if an USRP could help to find out more about #1024 after the congress, 
than we
can decide if it makes sense to capture GSM traffic when bug #1024 
occurs and
_maybe_ even play it back to reproduce #1024 (not sure if I am too 
optimistic
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 
we should
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.

Best regards,
  Dieter