On 5/9/13, Sylvain Munaut <246tnt(a)gmail.com> wrote: Thanks a lot - I just got it working! I've tested both voice and SMS, both MO and MT - all 4 worked for me on T-Mobile USA. At first it seemed to me that the master branch code wasn't working without this patch, but that turned out to be a pilot error on my part. Right now it seems to work the same for me with or without the patch. But I'm curious as to what that patch does, what does it fix, and if it fixes a real bug, why it isn't in the mainline... There one remaining issue of concern, though: every now and then, even though my mobile station under test is completely quiescent/idle and stationary, I see stuff like this pouring in the vty telnet window: OsmocomBB# % (MS 1) % Searching network... % (MS 1) % On Network, normal service: United States of America, T-Mobile USA Please pardon my ignorance if what I'm seeing is something completely normal and harmless, but it seems as if the mobile is periodically losing contact with the network and has to re-register, i.e., "bouncing". The phone's original proprietary fw doesn't seem to do anything like that - at my place it shows high signal strength (5 bars), and appears to be in a "totally solid" contact with the network. Is OsmocomBB mobile really making poor contact with the network (lack of RF calibration maybe?), losing this contact periodically and having to re-register, or do the messages indicate something else altogether? On the test voice calls I've made, the far end audio sounded just fine to me, and I was able to stay on the call long enough for the person on the other end to get bored - suggesting that the radio link is probably fine - but while idle/quiescent, it sometimes "bounces" a lot, sometimes so much that it's difficult to type a command line in without these messages interjecting. I didn't have to do anything special. Setting the IMEI to the proper value from the phone's shipping carton, switching from DCS to PCS by entering "no dcs" and "pcs" under "conf t" -> "ms 1" -> "support", and running with layer1.highram.bin compiled with Tx enabled made it "just work" - aside from the "bouncing" issue described above, and my pilot error of trying to dial an invalid number the first time I tried to make a call. Confirming: on this phone model, the "default" speaker is the earpiece one, or at least that's the one that gave me the audio when making or answering a call. Has anyone tried to get the loudspeaker to work on this phone? Thanks, I got it. Kim

On 5/12/13, Peter Stuge <peter(a)stuge.se> wrote: I thought that's what the "% Searching network..." line implied - or does it not? How else would I test it? If there is a loss of network contact indeed, it is rather brief, probably a little less than a second - hence a direct test of reachability for MT calls/SMS would be difficult. OK, I guess I can see that a phone has no way of knowing that it is stationary, so it has to execute that periodic procedure "just in case". But does this process require temporarily breaking the link with the current serving cell in order to check out the others? What if an incoming call or SMS happens to arrive right at that moment? All I'm saying is that to a "lay" end user seeing "Searching network..." in the UI means "oh sh*t, my phone is out of coverage or marginal - bad!". I'm trying to figure out if that is indeed what's going on, or if, considering the not-yet-for-end-users nature of OsmocomBB, the messages being printed by mobile mean something totally different from the naturally expected end-user meaning. Kim

On Mon, May 13, 2013 at 10:57:03AM +0200, Tim Ehlers wrote: probably the easiest fix is to have osmocon stop reading in the size of one and do the buffering inside the osmocon code.