Table of Contents

Some notes on E303 voice capability

FIXME this article is very WIP-y because I never finished this project, you've been warned. FIXME rewrite this disgraceful display of bad english writing, also consider tighting this this tl;dr crap up.

Huawei dongles are pretty ubiquitous. One of our local operators (Vivo, TIM etc.) used it a lot, in a myriad of different models. Mine, particularly, is a E303C, which happens to have voice support. Hence, it's possible to place and receive calls using such dongles. Under normal circunstancers, one would use the Windows app., which provides an integrated caller. You'll soon notice that there's absolutely no related multimedia devices on devmgmt.msc. It does that using only standard serial ports.

It was also possible to use it with Asterisk, which had a module called chan_dongle. From what I could tell by reading the code, it was designed exactly for this kind of situation – i.e. audio over serial port.

The basic theory

When you plug the thing to the computer, three ttyUSB things pop into your /dev. Two of them should accept AT commands, one don't. This strange port is actually where the PCM data flows through during calls. Theoretically, you should be able to place calls per via AT commands and then pipe data from this serial port into something like aplay, which should send the data to your DAC device, whatever it is. Better yet if you understand droid speak, because you won't need ALSA.

As you may imagine, there are several gotchas getting there from here, though. You'll likely run into issues regarding USB mode switching or you won't be able to find the correct PCM format to decode the voice data. Also, there are some specific AT commands you should issue, under some circunstances. This manual should help you with that.

Another common issue is the locked voice function. Mine came with unlocked (then I locked it when messing with different firmwares…) Unlocking it is a nightmare, the only way I could find was to pay some indians (I do not remember the actual name) to be able to unlock it.

In practice

Let's try to place a call.

Okay, real simple: first you need to get your PCM format. 

AT^CVOICE?                  <- The command you should send
^CVOICE: 0, 8000, 16, 20    <- The answer

OK

There's an explanation for what those numbers are at page 111 (113) of the manual I mentioned earlier. What's important: sampling rate (8000 Hz) and bits per sample (16). That means your stream will be a mono WAV stream using those settings.

Okay, let's open another terminal and make sure whichever comes through /dev/ttyUSB1 (it's the DIAG port most of the times, altough YMMV) pipes through aplay: cat /dev/ttyUSB1 | aplay -f S16_LE. There are some situations when aplay does nothing (happens to me when running this thing as a root user). In this case, just specify a device for aplay, e.g. -D “hw:0,0” (on doubt, run aplay -l and man aplay, I won't go through details, here).

You can also redirect data from your microphone stream to the serial port by doing as follows: sudo arecord -f S16_LE /dev/ttyUSB1. But I didn't test it, thus far. At the moment, I have no microphone connected to my desktop.

Then, go back to the console and issue the following command: AT^DDSETEX=2, to which the answer should be “OK”. It is now redirecting the audio stream thorugh the DIAG com port. Now you're all set to place a call. 

ATD+<your_aunt's_number>;
OK

The “+” is important under some circunstances. And the semicolon is of utmost importante. Without it, you just keeps getting “No carrier” error. Don't ask me why.

If your call succeeds, there'll be sound. ^CONN:1,0 seems to indicate your call have been picked up. Also, as soon as the audio streams hits the DIAG port, aplay should say something like this: Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono.

To hang up, just send the standard AT+CHUP command.

Yeah, it is crude. But it works. Be sure to check the references, as well.

References