Which is the best branch for running mobile on DP-L10?
Hello, I have just got myself a Pirelli DP-L10, and I would like to use it to demonstrate OsmocomBB to my local LUG. I would like to demonstrate mobile, talking to layer1 via osmocon, making and receiving a voice call, sending and receiving SMS. I only have a few basic questions: - Should I use the master branch in osmocom-bb git, or one of the other branches? The Branches page in the wiki is blank. - Am I correct in my understanding that, at least in some branch (see above), osmocom-bb does support this phone well enough to actually make a call? (Yes, I realize that layers 2&3 run on an attached host, hence the phone has to be tethered to a laptop running osmocon and mobile the whole time, and I do know how to enable Tx in the target build. :) - How is the voice routing implemented? Do I need to use lcr integration on the host, or will the audio come out of the phone's own speaker even though all higher layers of the stack are running on the PC? If the voice call audio does go through the phone's own speaker and mic, which ones? This phone model has both an earpiece speaker and a loudspeaker, plus the usual analog headset jack. Which of these audio routing options are supported, if any? Thanks everyone for this awesome project! I can't wait to show it working to my LUG. Kim
Hi,
- Should I use the master branch in osmocom-bb git, or one of the other branches? The Branches page in the wiki is blank.
Currently, master. If you have trouble establishing voice calls, you can try to cherry-pick df6269173cbc72e02964159cb60d2db712eb0f07 over master.
- Am I correct in my understanding that, at least in some branch (see above), osmocom-bb does support this phone well enough to actually make a call? (Yes, I realize that layers 2&3 run on an attached host, hence the phone has to be tethered to a laptop running osmocon and mobile the whole time, and I do know how to enable Tx in the target build. :)
voice & sms should work fine from the master branch. Some small code changes might be needed for the DP-L10 though, not sure, I never really use this phone myself so I can't say. The wiki might have more info and if it doesn't, feel free to update it once you figured it out.
- How is the voice routing implemented? Do I need to use lcr integration on the host, or will the audio come out of the phone's own speaker even though all higher layers of the stack are running on the PC? If the voice call audio does go through the phone's own speaker and mic, which ones? This phone model has both an earpiece speaker and a loudspeaker, plus the usual analog headset jack. Which of these audio routing options are supported, if any?
By default the audio will be router to/from the phone default speaker/microphone. That's because during normal phone function, the ARM and the higher layer never even see audio ... the audio frames are received, demodulated, decoded, decompressed and directly fed to the speaker all inside the DSP. The upper layer just configures the audio mode. We also added the option to route the audio frame to/from the PC in the firmware by using some special DSP mode but if you want to get the audio externally this is currently only possible with the LCR integration. (or you have to modify the code ...) Cheers, Sylvain
On 5/9/13, Sylvain Munaut <246tnt@gmail.com> wrote:
voice & sms should work fine from the master branch.
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.
If you have trouble establishing voice calls, you can try to cherry-pick df6269173cbc72e02964159cb60d2db712eb0f07 over master.
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.
Some small code changes might be needed for the DP-L10 though, not sure, I never really use this phone myself so I can't say. The wiki might have more info and if it doesn't, feel free to update it once you figured it out.
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.
By default the audio will be router to/from the phone default speaker/microphone.
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?
That's because during normal phone function, the ARM and the higher layer never even see audio ... the audio frames are received, demodulated, decoded, decompressed and directly fed to the speaker all inside the DSP. The upper layer just configures the audio mode.
Thanks, I got it. Kim
ubuntugirl wrote:
it seems as if the mobile is periodically losing contact with the network and has to re-register
Is it actually losing contact? Is it the cell re-selection procedure? Terminals periodically scan for surrounding cells in order to switch if they see a better one. //Peter
On 5/12/13, Peter Stuge <peter@stuge.se> wrote:
Is it actually losing contact?
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.
Is it the cell re-selection procedure?
Terminals periodically scan for surrounding cells in order to switch if they see a better one.
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 Sun, 12 May 2013, ubuntugirl wrote: Hi,
Is it the cell re-selection procedure?
Terminals periodically scan for surrounding cells in order to switch if they see a better one.
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". [...]
you can set "no neighbour-measurement". This would turn the re-selection off. I have identified the neighbour-measurement as one of the reasons, why my phone is crashing from time to time. I think that is because of the burst-data sent from layer1 to layer23 over serial and somehow is not completely flow-controled: kernel: [900845.794906] ttyS7: 1 input overrun(s) These messages don't disappear, but are more seldom, since the data between the layers is reduced. So my advice at the moment is to disable neighbour-measurement, when using the phone stationary. Cheers Tim
participants (5)
-
Holger Hans Peter Freyther -
Peter Stuge -
Sylvain Munaut -
Tim Ehlers -
ubuntugirl