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 _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
