Stupid idea rattling around my head...

Can I hack in support for the unsupported Phone Book Access Profile and use it for a text to speech type menu system? Like something where you have a list of possible commands and a bluetooth peripheral designed to read your address book to you and let you select a name instead reads a menu to you and lets you select a menu item?

David

Almost certainly. While I'm not quite sure on the details, pretty much anything that can be done on a desktop Linux machine should be possible to get working on an NIT, one way or the other.

-John

That's an interesting question. However, the problem I see is that bluez d-bus stuff does not yet support a lot of BT profiles e.g. HFP and Gateway are still missing.

Actual PBAP would require Bluez hacking.

If you want to pull down the phone book from a device, research that device's AT command set (or the GSM extension set) --- it's pretty easy and works over the serial port / DUN profile. It's how gnokii works, et al.

After some sober thought... I don't think what I was envisioning would work.

I was thinking about trying use a PBAP device to control a piece of software totally unrelated to the address book. I think maybe a better choice would be to rig up a bluetooth enabled SPP device to some buttons and switches. Everybody supports SPP.

Edit: Or what about AVRCP? Stupid idea but let's say I'm in my car driving along with Maemo mapper running on my N800 on the dash and my Jabra BT620S headphones on. Could Maemo mapper be hacked so that the music controls on my headphones zoom maemo mapper in and out?

David

I think what you were envisioning would work, as would your new plan. The trouble is implementing it. Any protocol that transmits data can transmit any data, given an appropriate encoding. Encoding a menu (list of options, choose one) as an address book (list of identities, dial one) is sane. So is encoding a list of commands (with names like zoom in and zoom out) as a list of commands (with names like volume up and volume down).

Either of these would work, and neither would be the 'correct' solution. (Correct solution would involve avrcp, but using other commands than your headphone provides.) As such, they would risk conflicts when, someday, software is released that implements these profiles and uses them for their proper uses. But that's what you get with hacks, and on the bright side, Nokia probably won't be releasing an OS with such functionality for a long time (if ever).