Bluetooth to 2410 Wiring

Wally Ritchie wally.ritchie at gmail.com
Fri Jul 27 08:55:33 CEST 2007


On 7/26/07, Harald Welte <laforge at openmoko.org> wrote:
> Hi Wally!
>
<snip>
>
> Well, the main issue seems that none of the core developers in this
> project seems to have ever used bluetooth at all.  To me it is still
> this somewhat strange technology, that I have used about five times
> with consumer equipment to exchange contact data between phones.  That
> is, I enabled it for about two minutes each time, then disabling it
> again.  For security reasons, having a enabled (even non-discoverable)
> bluetooth doesn't really seem to be a good idea, at least with
> non-updatable consumer handheld devices.

OBEX push of business card, pictures, etc. is just one of many BT functions.
My kids use it all the time as do many people in Singapore, PRC, HK, etc.
But this kind of app is a sideshow that doesn't have any power
management issues.

Once two BT devices are paired, they have shared keys and are probably more
secure than GSM. BT is vulnerable, however, during pairing, where in GSM the
equivalent of pairing is done by the operator who, unlike the consumer, knows
what he doing vis a vis security.
>
> But even after many, many days of time put into it, I still have not
> managed to get any of my three bluetooth keyboards to work on any of my
> linux machines.  It seems that it is intertwisted with complex things
> like dbus, that I definitely do not want to have on my machines due to
> its resource usage.
>
BlueZ stack seems to be intertwined with dbus. I have not done enough testing
to know how reliable BlueZ is. My kids use BT keyboards and mice a lot without
problems on their laptops and tablets but I haven't tested them on the linux BT
stack (I'm about to). Some of it may simply not work but we can fix that can't
we ;-)

> In any case, I actually have to admit that I don't see a reason why
> wakeup from bluetooth is that important.  In which particular scenario
> would you use this?
>
The key driving force of BT is power. BT lets two bound devices sleep in a
periodic scan mode for about 1 or 2 mw. Either can wake the other up in about
two seconds. There are other modes with even lower power where a low power
device can be parked on a higher power device. The main point is satisfying
particular use cases with low enough power to give good battery life.
You usually
can't get way down in power without drastically lowering the duty
cycle. We don't
need to be concerned about deep sleep states if we have enough power.

A reasonable minimum target is probably 40 hr of standby plus 8 hours
of operation,
i.e. talk time or media time. If the 4000 mwhr is split between them, the budget
is about 50mw standby and 250 mw operating. If we can drop the standby from 50mw
to 25mw, the talk time can increase 50%. The BT part can get under 1mw.
The GSM radio i'm guessing is about 20mw. Of course, if we are
maintaining a GPRS
session it will be higher and we can't sleep anyway and for some scenarios GSM
can be off. Then again, if operating is more like 500mw the savings
from sleep could
take you from 4 hr to 6 hrs.

If we don't sleep, then BT wakeup is a non-issue. If we need to sleep
to make power
budgets, then we should be able to wakeup from GSM or BT and I'll explain why
below.

> Once the cpu is in POWRE_OFF mode (that's how samsung calls their
> suspend-to-ram mode), it actually takes significant time to 'boot' into
> the existing RAM image again. (It first starts by loading the first 4k
> of NAND into SRAM, executing the bootloader, taking SDRAM out of
> self-refresh, jumping into the kernel, then re-enablign all the various
> hardware devices).
>
It might be hard to handle GPS stack under these conditions but I suppose
you could get serial port working early on in the resume. I don't know know
enough about the kernel power management (yet) to comment. Looks to me
like there are resume problems in lots of drivers in the wild. This is true also
in the windows world.

I am beginning to think that slow mode may be the way to go for the current
generation until all the PM issues can be more fully explored. Resume probably
needs to be on the order 1 second max, preferably a few hundred ms.

> If I was to use bluetooth, then I would explicitly connect to some other
> device, let's say another phone.  As long as that transfer is ongoing,
> would you want to suspend between the individual packets?  That's way
> too short timeframes.
>
You would never suspend with an active connection. That connection will
cost about 20-40mw. (I shudder to think what WiFi will cost but i'm
hoping it will be acceptable). BTW there are some use cases where BT
networking may still be preferable to WiFi due to power issues. For example,
it would be nice to transition from GPRS when away from home or office
to BT when at home or office. For low throughput, BT is lowest in power
followed by GPRS followed by much higher powered 802.11. For this reason,
Class 1 BT for some use cases may be preferable to 802.11.

> And if I think about BT headset use, then its use is always connected to
> an incoming or ougoing call, i.e. the CPU will have to be woken up by
> either the GSM modem before, or by the user dialing a number.
>
or by me pressing the button on my headset to wake up the handset in my pocket
to voice dial. This is a 5 year old use case many people (including me, my wife,
and kids) use every day. You break a common pattern if you can't support it. I
could do this on pretty ordinary handsets even 6 years ago. The handset stays in
pocket purse or briefcase. 8 years ago when I was one of the only people in the
U.S. with a BT headset they used to stop me and ask me if I was in contact with
the mother ship. Today, people who could barely use AOL have them.

I can think of an awful lot of things that could be done with voice/IO
on this platform
while leaving the device in my pocket with LCD off. Press the button on by BT
headset, tell it what to do, tell it go back to sleep.

> And if you want to set your phone discoverable to ceate a
> connection/association with another device, then that, too. will have a
> manual 'set phone discoverable' event before, and not be autonomously
> woken up by bluetooth.
>
Paired BT devices do not have to be made discoverable. The low power end
can SCAN for the active end. For example, let's say i want to have a BT
device supporting cordless telephony profile connected to by PSTN at home
or VOIP gateway. On reaching phone or office, an openmoko smartphone could
configure itself to scan for the gateway. The smartphone can then sleep and be
awakened by either GSM or BT. BT would awaken the handset on an incoming
VOIP (or PSTN or intercom) call. In fact, this would probably be many people's
preferred method. Why another phone - why not one phone for all phone use cases.

> In fact, the more I think about it, the lesser I like the idea of this
> capability.  Why would I want my phone to wake up and draw power for
> something that I didn't explicitly request it to do?
>
You want it to wake up and draw power to do something that you set it up
to do on some set of conditions. (e.g. when your press the button on your
BT headset, receive a VOIP call from your gateway, or some killer app we
haven't thought of that gets enabled by the capability.

> Maybe you can educate me.
>
> I'm not really arguing against producing hardware that has this
> technical capability (as long as we can do it given the resources we
> have).  But I somehow doubt its general usefulness.
>
You are building a platform for the long term along with its first
generation of hardware.
We are opening new vistas precisely because this platform is an enabler for what
no one has thought of. I think we need to think in terms of enabling
more and more
use cases because by doing that we end up enabling the use case that has not
yet been discovered. We don't have to wait 2 years to test that new
use case. Just
put it on an openmoko platform NOW and start making money if money can be made.

You're not going to get the hardware platform right - on the first or
even second go.
Never happens. You are going to evolve models. Unlike a traditional
handset, you're
not implementing hardware to meet an already defined functional spec. You don't
know what software is going to end up on the platform. You don't need
to evaluate
all of the use cases and decide which ones to support for this model because the
model evolves for a couple more years in software after you are on to the next
hardware platform. The design choices in hardware are then made on the basis
of  "could this under some scenario be useful". If so put it in,
especially when it is
just wires on the board. I think you already think this way but the
FIC hardware guys
are probably not used to this. BTW if I was designing this board, I
would have a Xilinx PLD
doing this routing of wakeup signals and other crap. Why pin it down and commit
it when you layout the board? In system programmable PLD's can open a lot of
possibilities for NT$10. Same for PCM audio streams.

If you can't get BT wakeup now, it might not be of too much practical
significance
if we can't resume in a second anyway. But it would be nice to have it on the
future hardware roadmap for the day the software issues can be resolved. We're
six months from just basic reliable handset feature set.

BTW I think you have done a tremendous job for the first hardware, far
better than
anyone could  have dreamed of.

Feel free to PM if you want to follow-up off the list.

Cheers, Wally
> --
> - Harald Welte <laforge at openmoko.org>                   http://openmoko.org/
> ============================================================================
> Software for the world's first truly open Free Software mobile phone
>



More information about the neo1973-hardware mailing list