> sigh! personally if the firmware just ignored the camera and wlan stuff > I'd be happy, but I don't doubt what you say, both about the replacement > mboard route and using the hardware as is
If only the camera and WLAN stuff would just stand out of the way for regular phone functionality... But alas, it does NOT just stand out of the way: the path to the display goes *through* the undocumented SPCA552E camera chip, hence we have to deal with that nasty chip if we want to put anything on the LCD or even turn it on. I borrowed the knowledge of how to do this part from OsmocomBB - and whoever figured it out on their end has done a really heroic reverse eng effort to get this far. But the trouble does not stop there: when I tried to play with the W56940 ringtone generator and loudspeaker driver chip (required if we want to make the phone ring or to use the hands-free loudspeaker for calls), I started tracing out the connections to this chip (OsmocomBB folks never touched it, so I have to figure it all out on my own), and I saw that the reset line to the ringtone chip comes from guess where: from the same darned SPCA552E! I did not try to go any further, as it would be pointless without knowing how to control the reset line. Well, OK, we may still be able to make the Pirelli phone vibrate even if we can't make it ring: in the last couple of days I made a purely accidental discovery (I was playing with the AT@SND debug command I added to Magnetite fw) that Pirelli's vibrator is hooked up to the Calypso output that was originally meant for the piezoelectric buzzer (like on Mot C139), thus trying to ring the piezo buzzer on the Pirelli turns on the vibrator instead. But would you want a phone that can only vibrate but not ring on incoming calls and SMS? And the W56940 ringtone chip is not just for ringing, one has to turn this chip on and do some magic to it in order to use the loudspeaker for calls as well - and if we sacrifice the hands-free loudspeaker function, that is one of the main advantages of the Pirelli over the C139 for me personally... > > I've also been doing some work on ringtones - I'll post an explanation > > a little later, it's bedtime for me now. > > For me that's another issue - the Pirelli excels here, but the c139 > (at least the models I have) are so quiet I often don't hear a > incoming call. When I said I was working on ringtones, I wasn't talking about the loudness of the ring, I was referring to the great technical challenges involved in playing any kind of ringtone at all on our own phone, be it our own hw+sw or just our own sw on alien hw - but since you've mentioned ring loudness, for me that is another area where Pirelli's proprietary fw is misdesigned. One of the big problems I have with Pirelli's fw is that they have only one volume setting that is global across all modes: the ring volume is the same as the earpiece volume in calls, which is also the same as the in-call volume in loudspeaker and headset modes. So if I turn the ring volume all the way up so I can hear it when I'm outside or when I may be some distance from the phone, I then get a blast in my ear when I make or answer a call, so I have to turn it down to talk comfortably - and if I subsequently don't crank it all the way up again, I might not hear it when it rings. A huge defect for me. What makes Pirelli's bug in this regard so ironic is that TI's reference code already contains a proper solution to this very issue, as I have also just discovered in the last couple of days. Openmoko put a file in their modem FFS (programmed into every unit on the production line) called /aud/para0.cfg, and added the non-standard AT@AUL command that requests the RiViera Audio Service fw component to load this audio config - but this function has always been broken (AT@AUL always returns ERROR and does nothing) even in their original moko10/11 firmwares. As I was investigating this oddity, I learned that TI's Audio Service requires these audio config files to come in pairs: for every *.cfg there must also be a corresponding *.vol file, and it will refuse to load the *.cfg if the corresponding *.vol is missing. Because there is no /aud/para0.vol in Openmoko's factory FFS programming (you can now trivially add this file yourself with fc-fsio, but this is besides the point), the programmed /aud/para0.cfg profile cannot be loaded and this whole piece of functionality never comes into play. Clearly Openmoko Inc. did NOT have a Calypso modem engineer of my level on their staff: they had the source for far longer than we have, and yet they failed to do the job properly - draw your own conclusions.. And just why does TI's Audio Service require a volume file to come along with every audio config file? Answer: to solve the very same problem that is exhibited by Pirelli's fw! In TI's solution the volume setting exists as a per-config datum: each audio mode has its own corresponding volume setting, and whenever you turn the volume up or down while in a particular mode, the Audio Service automatically updates the *.vol file in FFS for your current mode. If you then switch modes, the volume instantly switches to the last saved setting for the new mode, and when you switch back to your previous mode, that mode's saved volume comes back. They got it right! Now why did Foxconn (the makers of the Pirelli) not simply follow TI's reference.. This point about how Pirelli's and other production firmwares for various historical Calypso-based phones always seem to do things differently from how TI's reference fw does them comes back full circle to our original problem: the code from TI for above-the-modem handset functionality is utterly unfinished and unusable as-is, hence the phone manufs had no choice but to finish themselves in their own ways what TI failed to deliver.. But it gets even more complicated as TI's reference fw actually contradicts itself in many places, i.e., different parts of the fw (developed by different TI groups with very different coding styles) exhibit different "vision" as to how things should work. TI's Layer1 and all code in the RiViera land was developed in France, the G23M protocol stack and ACI were developed in Germany (former Condat), and the pathetic demo/prototype/reference UI code you've experienced with FreeCalypso on the C139 was developed by Condat-UK turned TI-UK. What is the "proper" or "canonical" way to produce ringtones on a Calypso phone that is equipped with a loudspeaker instead of a piezo buzzer? Whatever answer the people at TI back in Those Days had in mind, I don't know it, and the code we have strongly suggests that different people at TI had very different ideas in this regard. On the one hand, the Calypso DSP and Layer1 supposedly provide a way to generate melodies internally within the DSP itself (the so-called Melody E1 and Melody E2 features), so the phone manuf won't need to do anything more than hook up a "dumb" (purely analog) audio amplifier between Iota's AUX output and the speaker - and automagically get a loudspeaker that works for both ringtones and hands-free calls. But I have never seen a real-life Calypso phone (well, OK, our knowledge is limited to the set of models discovered and documented by OsmocomBB, which is a very small sample, but still) that works this way. Instead the two Calypso phones in our known set that have loudspeakers instead of piezo buzzers (Mot C155/156 and the Pirelli) both use external MIDI player chips. In Pirelli's case they seem to have routed the Iota's headset output (not AUX) to both the headset jack and their W56940 MIDI chip, and when their fw turns on the loudspeaker for calls, it must be doing something to the primarily- for-ringtones MIDI chip to make it amplify the external analog input instead. With Mot C155/156 it's even worse: Mot never listed hands- free loudspeaker as a feature at all for this model, their fw offers no such mode, and we don't know if it's an artificial fw limitation or if there is some issue with the hw as well. This loudspeaker ringtone generation issue will be a really sticky point for us when we get to building our own Libre Dumbphone hardware, but I'm going to leave this story for another day. M~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
