This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
ubuntugirl ubuntugirl2013 at gmail.comOn 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