Success: Two-way phone call with Treo 650 in Linux

Now that I have a VOIP account that can make unmetered calls to mobiles I decided to try having a play with getting two-way phone calls working from Linux on the Treo 650. I turned on the phone part in Palm OS, booted this kernel and reset the power on the gsm module with:

echo 0 > /sys/devices/platform/palmt650-pm-gsm/power_on
echo 1 > /sys/devices/platform/palmt650-pm-gsm/power_on
echo 1 > /sys/devices/platform/palmt650-pm-gsm/wake

I then fired open minicom and opened /dev/ttyS0 at baud 460800 without flow control. I then connected the modem to the network and entered my subsidy unlock pin:

AT+CFUN=1
AT+CPIN="xxxxxxxxx"

Once connected, I called my phone via VOIP and then answered with the ATA command:

RING
RING

ATA
OK

At that point I opened up a few terminal windows and started fiddling with ALSA. I first started playing some white noise so I could heer when I started transmitting:

cat /dev/urandom > /dev/dsp

I discovered you can divert PCM to be transmitted by the phone using:

      Master Mono: Enable, set transmit volume
              PCM: Enable, set PCM volume
PCM Play to Phone: Enable to route PCM signal to the phone module

After some more fiddling I routed the microphone to the phone. The labeling of the Mic controls in the ALSA driver is rather strange but here are the key settings:

      Master Mono: Enable, set transmit volume
Mic Select Source: mic1=handset, mic2=headset
            Mic 2: Selected mic volume
   Mic 1 to phone: Enable/disable handset mic 
   Mic 2 to phone: Enable/disable oheadset mic
   Mic 20dB Boost: Useful in speakerphone mode, you can talk from quite a distance.

Mic 1: [irrelevant?]
Mic select:  [irrelevant?]

After that I managed to get the incoming audio going out the handset earpiece with these settings:

         Master: Enable, earpiece volume
Master Left Inv: Enable
          Phone: Seems you don't need to unmute, but need to set volume.
Phone to Master: Enable
            Aux: Set a high volume (weird stuff happens if low)
    Out3 LR Mux: Master Mix (mislabeled, it's actually out2)

I've made an ALSA state file for working two-way phone audio with the handset.

Hello! Hello?!

Well there's been much progress. I've basically finished off the kernel driver aside from waking the CPU from suspend upon an incoming call. Also adding basic BCM2132 to gsmd turned out to be a fairly simple procedure aside from some strangenesses of the platform. See the gsmd list for my patches. So now we can make and receive calls and SMS with the only remaining problem being routing of audio.

I've setup a skeleton SoC audio driver. This is enough after some fiddling with alsamixer to at least be able to hear what the other person says but outgoing sound doesn't work. The diagram to the left shows how I think things are wired up and should be of use to anyone trying to understand the huge number of alsamixer controls. At the moment I'm trying to get OE building an OpenMoko image with MACHINE=palmt650. :-)

Wake up!

I've been playing around with the Treo's GPIOs and I've finally discovered how to prevent the GSM module from going to sleep! Setting GPIO 57 high seems to force the module to stay awake. I also discovered GPIO 11 is a wake signal from the GSM to the CPU. This GPIO has a rising edge whenever some message is sent (or is ready to be sent) .

Also, while CTS seems to be always set when the GSM is powered, it will queue data while RTS is deasserted. So while in sleep we should probably deassert RTS, wait for GPIO 11 to awaken us (on eg incoming call) and then assert RTS to receive our data.

Trying to put all this information into a driver is going to be interesting. I wonder how pluggable the PXA serial driver is. Maybe I'll have to resort to just keeping the modem constantly awake for now.

Update: On first glance set_txrx() may do the trick.

*Ring* *Ring*

I figured out the trick to making calls with the GSM modem in the Treo 650, you just need to give it the subsidy unlock code with AT+CPIN="xxxxxxx". I also found something else interesting:

AT+CFUN=6
The handset is in Calibration Mode:
                                   

********Main Menu:********
                          
0  HELP                   
1  ARFCN arfcn
2  MODULATION 0=GMSK/1=8PSK
3  DACVAL FREQ_DAC_ZERO    
4  ALL_RAMPS           
5  RAMP_SELECT txlev(0-19)
6  AGC rxlev              
7  GSYS band step
8  START 0=norm/1=rach
9  STOP               
10 OAKWR addr val
11 ARMWR size addr val
12 ISPCS 1=TRUE       
13 OAKRD? addr 
14 ARMRD? size addr
15 RXLEV?          
16 GSYS? band index
17 MULTISLOT       
18 EN_AUTO_SIM 
19 L1 TEST     
20 EDGE/GPRS TEST 
21 TXDB_WRITE Row(0-7) [v0 v2 v3 ....v15]
22 CHANGEMODE mode :0=normal,1=cal,2=download

It doesn't respond to commands after that. I guess it may be expecting some binary protocol.

I'm still having the problem of after receiving *MRDY: 3 after powering on the radio the connection seems to freeze up. Messages are still received it's just outgoing keypresses that seem to be ignored. I found if I hold down a key long enough it'll eventually receive it and I can issue commands like that. Something strange must be going, perhaps there's some time window which it will receive in.

If I pull out the SIM the device will drop to MRDY: 5 and the AT console becomes usable again. Curious.

Update: Ah. I've found references to something called cyclic sleep mode. So perhaps the baseband goes to sleep for some cycles and then wakes up and can receive commands again.