Which is the best branch for running mobile on DP-L10?

ubuntugirl ubuntugirl2013 at gmail.com
Mon May 13 01:01:49 UTC 2013


On 5/9/13, Sylvain Munaut <246tnt at 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




More information about the baseband-devel mailing list