FreeCalypso update: progress with DSP patches and voice calls

[Mychaela Falconia]

Thank you David and DS for your feedback.  Regarding the direction our
project should take, I'll write more about it later when I'm more
awake - it's close to bedtime for me now. :)  But let me just address
a few quick technical points:

> I will try your suggestion of testing with only FR speech codec,
> it will be a quick test.

When I get a call connected (either MO or MT) on Operator 310260's
network running gsm-fw with the DSP patch applied (connection succeeds,
but noise in the earpiece instead of expected downlink audio), I get
very voluminous debug output that looks like this:

[17:40:13] L1: AMR 10469
[17:40:13] + 025b 0004 0002 0014 ffcb 001a 0000 0003 0000 0000 0000 0000 913b 
[17:40:13] + 0023 000f 0004 0000 0000 0000 0000 0000 0001 0003 0000 0000 0000 
[17:40:13] + 0000 0000 0000 0000 

The number after "AMR" is the frame number, and a blurb like the above
gets emitted every 4 to 5 frames - I'm guessing it corresponds to a
20 ms block of audio.  Having that blurb emitted 50 times per second
is a *lot* of debug output, I'd say too verbose for the default, so
I'll probably change the default to have it disabled.  But what I don't
know is whether or not this debug output indicates that AMR is in fact
in use - so when you run it against your test network with the plain
FR speech codec, I would like to know whether or not this AMR debug
output occurs.

> By the way, how do you load this ALSA
> scenario on the AP?

You have QtMoko installed on yours, right?  If so, the necessary files
should be in your file system already.  First, find where the
gsmhandset.state file is located:

find / -name gsmhandset.state -print

Then when you have the regular QtMoko environment shut down to play
with the Calypso manually, load this ALSA scenario like this:

alsactl -f /path/to/gsmhandset.state restore

I found empirically that the earpiece volume is too low, so I do two
things to turn it up:

* I edited the control.4 setting in the just-mentioned ALSA scenario
  file, upping it from 115 (what it came with) to the maximum of 127.

* Give the GSM firmware an AT+CLVL=255 command: it sets the audio
  output volume to max at the Iota ABB level.

Oh, and one has to use the earpiece; the loudspeaker cannot be used
simultaneously with the debug serial channel being enabled - a real
inconvenience. :(

> I think you are right regarding the LoCosto L1 code: it is quite
> possible the source of our other issues,

Yup, non-working deep sleep is surely one of those.  (I checked, and
it is still broken after the static DSP patch fix.)

> and I concur a careful
> disassembly of the GTA02 firmware blobs might be necessary.
> Although reading ARM code is not trivial for me, I can try and give
> it a shot! And since we have the whole proprietary toolchain in
> place, I could verify that the reconstructed C code compiled to the
> same assembly code as the pre-compiled blob.

I just created this:

https://bitbucket.org/falconian/tcs211-l1-reconst

There is a README file in there explaining what to do.  I plan on
doing the 6 l1_dyn_dwl_*.c modules first, so if you would like to try
your hand at this stuff in parallel, I would suggest you try l1_async.c
out of the core set of L1 modules.

> Now regarding on the direction you are considering to take for the
> next weeks/months, it's difficult for me to say; what is true is
> that your time is quite precious considering the expertise you have
> in the matter at hand,

Thank you for the compliment!

> so it's probably best to concentrate on tasks
> that may require the broad knowledge of Calypso you have, indeed the
> hardware side of things is evidently of interest.

Too tired and falling asleep to think clearly right now; I'll revisit
it later.

> Now regarding the
> PCB design, since I don't really know the subject I can't really
> recommend anything -- but on an ethical POV it feels better to help
> existing FOSS projects (such as gEDA or Kicad) than being forced to
> use proprietary tools because the original Openmoko creators used
> them years ago.

Regarding the ethical POV - yes, those are my exact same thoughts.  I
don't like the idea of remaining beholden to proprietary ECAD tools
forever.  But again, I'll write more later.

M~