BatPhone on Nexus One + Minor Fixes

[Paul Gardner-Stephen]

Hi All,

Two good fixes this morning here in the dark at work while they fiddle
with the power.

1. BatPhone is now running on the N1.
2. I have optimised the connection process to cut down the call
connection time to <20 seconds, including the whole process of playing
the voice prompt and getting the user to confirm it.
There is probably scope to shave a few more seconds off, but it is now
way better than it was.
Also, once I add the code to allow trusting a subscriber, the voice
prompt will be entirely bypassed,
and the call will be able to proceed almost as fast as the old IP
dialing on a mesh potato.

Files at http://groups.google.com/group/village-telco-dev

The next challenge is to sort out the acoustic echo.
The frustrating thing of course is that the phone has hardware for
this, but it is not turned on when an application uses the audio path,
only when a "real" phone call is in progress.
Also, switching to speex is problematic at this point, as Asterisk
claims not to know how to convert between GSM and Speex, so it refuses
to use the GSM encoded audio files. Both need working on, really.


Paul.

[David Rowe]

Hi Paul,

> The next challenge is to sort out the acoustic echo.

It would be worth measuring the echo path first. To do this send frames
of impulses and record the speech samples coming back. Then plot them.
This is the impulse response of the echo path. I can tell you exactly
how to do this off line if you like.

Might be a LEC like Oslec can handle it if the echo path impulse
response is short.

Good background is my series of posts on echo cancellation linked from
my oslec page:

http://www.rowetel.com/blog/?page_id=454

> Also, switching to speex is problematic at this point, as Asterisk
> claims not to know how to convert between GSM and Speex, so it refuses
> to use the GSM encoded audio files. Both need working on, really.

You don't need to use the Speex codec to use the Speex AEC. Also we
have patched Asterisk to work with Speex for the MP. But to be honest
I'd stick to a-law codecs for now, the BW savings over mesh networks are
not huge and it's one less thing your CPU has to worry about.

- David

>
> Paul.
>

[Paul Gardner-Stephen]

Hi David,

On Jul 24, 7:02 am, David Rowe <da...@rowetel.com> wrote:
> Hi Paul,
>
> > The next challenge is to sort out the acoustic echo.
>
> It would be worth measuring the echo path first.  To do this send frames
> of impulses and record the speech samples coming back.  Then plot them.
> This is the impulse response of the echo path.  I can tell you exactly
> how to do this off line if you like.

That would be great, as it really will make the system much more
usable and presentable to get the echo sorted out.

> Might be a LEC like Oslec can handle it if the echo path impulse
> response is short.
>
> Good background is my series of posts on echo cancellation linked from
> my oslec page:
>
> http://www.rowetel.com/blog/?page_id=454

Have started reading those in preparation for this.

> > Also, switching to speex is problematic at this point, as Asterisk
> > claims not to know how to convert between GSM and Speex, so it refuses
> > to use the GSM encoded audio files.  Both need working on, really.
>
> You don't need to use the Speex codec to use the Speex AEC.  Also we
> have patched Asterisk to work with Speex for the MP.  But to be honest
> I'd stick to a-law codecs for now, the BW savings over mesh networks are
> not huge and it's one less thing your CPU has to worry about.

True, especially since the UDP overhead basically doubles the
bandwidth required for GSM or Speex, so there is relatively little
saving.

Okay, so the plan would seem to be a-law codec + try to get OSLEC into
SIPDroid (which would make lots of other people happy as well).

Paul.

[Paul Gardner-Stephen]

Annoying update: The N1 only works intermittently. Specifically, the
wifi interface only receives packets when it feels like it. They get
sent (tcpdump on another phone proves this), but it only receives
packets from other phones some of the time.

This is likely due to it using 802.11-DS instead of b/g modulation.
This means it will not hear packets sent using the newer modulations.
What is annoying is that the radio *can* do 802.11n ! But iwconfig
eth0 modulation 11b etc does not work, complaining about "endpoint
does not support".

So at present N1 to N1 should work fine, but N1 to Dream and vice
versa is still problematic.

Paul.

On Jul 24, 7:39 am, Paul Gardner-Stephen