gentoocar

How bout Bluez Handsfree Service (BzHFS)? Linux Handsfree?

MP3Car.com

 

Zimans

BlueSqueak

What will the goal of this project be? A stand-alone application? A library?

I guess the question I have is what will we be doing with the audio once we have it. What tells the program what to dial etc?

Just looking to see what the direction of this project is going to be?

--Zims

__________________
--------------------------------------------------------------------------------
Now, Where are my Pants?

gentoocar

Good question. I am thinking a daemon running in the background, which communicates to some frontend app through pipes. That way, you can read in from statusPipe, and when you see "INCOMING_CALL 123-4567" you can display that to the user and then either write "ANSWER" or "REJECT" to cmdPipe.

I suppose I should also write some sort of basic frontend app so people can actually use (and test) it without writing their own frontend, but I gather most people building a Linux carpc here are writing their own frontends? I think it might be best to focus on making an easy API to integrate this into a frontend.

How would YOU like to see it work? I'm still open to suggestions. My frontend is all Java though, so I'd like it to be easy to use from any language (i.e. not just a C/C++ library).

Oh, and bluesqueak seems to be somebody's university project already. Bummer.

kev000

I agree that a background deamon is the best way to go. It'll be language unbiased. Great work! Just make sure to document it well so we can use it in our front-ends.

thanks

__________________
LinuxICE - because my car already has enough windows (and because I like speed).
LinuxICE2 beta2 is released!!! get it now!
Follow OpenICE development

nasa

Hi,

I too love the idea of a dameon, however, I was wondering about the use of java. Since a lot of us are using lower powered systems, perfermance is always an issue. Java adds some overhead that I'm not sure we would want.... This is only my 2 cents, since I'm not coding anything (yet) -- I will defer to your much appreciated efforts

Nasa

nasa

I shouldn't read messages so quickly....

Your only refering to the frontend

Nasa

gentoocar

Yes, java for my frontend, the daemon will be written in C++.

Zimans

My original idea was a c/c++ library, but nix that I guess :P Unless someone wants to create java bindings. (Or Ruby, or Python, etc)

So a daemon huh. I'd suggest using sockets over pipes (Unless that is what you meant), be it UNIX-sockets or tcp/udp.

Is this something that will be started by the front-end app, or will it be started as a system service? Is this something that has to be able to handle multiple apps trying to access it? Or will it be owned by the spawning app, possibly using stdin/stdout.

Will configuration be done before hand through a .conf file? Will the daemon simply start and wait for a controlling entity to tell it what to connect to. Will it just try to connect to any phone that happens to wander by?

Bluetooth has a scan mechanism, but I was noticing that when I had an active connection to a device and I was scanning, I had problems. However, I have a broadcom based dongle, so needless to say it's not 100% to spec nor 100% supported (I should probably look for a CSR dongle).

I suppose the daemon could have a list of devices to be on the lookout for and either periodically try to connect to them or periodically scan for them. Then once it does find a device either connect immediately, or notify any connected clients that a device has come into range and await further instruction.

Another possibility is instead of a daemon just have some utility apps that are spawned from a client. For example, a bluectl app that you send cmds via stdin and it replies via stdout. When it is time for audio, spawn bluesco with a bdaddr as a param, then it listens for a connection (Or establishes one) and sends any data it receives on stdin to the device and sends any data from the device to stdout. You would also have to call hcitool scan to get any nearby devices to know when to try and connect.

I can't find this project you were talking about for BlueSqueak....

--Zims

__________________
--------------------------------------------------------------------------------
Now, Where are my Pants?

MP3Car.com

 

gentoocar

Hmm. I'm not sure, really. I was going to use mkfifo to create a "named pipe" (at least that's what it's called in the windows world), and then open that like a file and read from it or write to it. Is there a more efficient way of doing this? I'd like the least amount of lag possible.


That's up to you. I was going to make a --nodaemon parameter so you could either start it as a system service (that's what I will do), or start it up from your frontend and own it.


Yes, there will be a conf file. It will, among other things, contain the list of named pipe locations (so you could have /tmp/audioIn or ~myhome/carpc/audioIn) - assuming I go with these named pipes.

I had come up with two ways for it to behave:
#1.
when nothing is connected, it will scan for devices that appear to be phones that support handsfree. Whenever one comes in range or goes out of range, it will send the list of nearby phones to the frontend.

Also, it listens for incoming connections. When you tell your phone to connect to your PC, it will connect as a handsfree kit. Scanning would still go on in the background, if this works (I haven't tried with my adapter).

The frontend can also tell the handsfree service to connect. It can send multiple bdaddr's, and that will be the priority. i.e.
CONNECT <myphone> <yourphone>
That means as soon as myphone is in range, it will connect to it. If myphone is not in range, but yourphone is, it will connect to yourphone. If myphone then comes in range, it will not disconnect. But then if yourphone is disconnected, it will connect to myphone.

The frontend can also say DISCONNECT, which will drop the connection and not try to initiate any more (but will still listen for incoming ones). Or you could say SWITCH <bdaddr1> <bdaddr2>, etc. to re-prioritize the list and reconnect to the highest priority one.

I know that sounds a little complicated, but I think I'm just not explaining it well. Simplest case, you don't send any CONNECT string, and just wait for somebody to click connect on their phone, like most headset earpieces. Or, if you only have one phone, use CONNECT <myphone> to auto-connect to your phone whenever it is within range and DISCONNECT to stop auto-connecting.

#2.
This is a little simpler (for the handsfree daemon). It constantly scans and reports in-range and out-of-range occurences to the frontend. The frontend can say CONNECT <bdaddr> for a single shot connection, when the connection dies (say the device goes out of rantge then comes back in) the frontend would have to re-issue the CONNECT to get it to reconnect.

It would also listen for incoming connections with #2, just like #1.



Good point. The right thing to do would be to solve that. The easy thing would be to assume only one program will ever try to access the handsfree service at a time. I can't imagine a realistic situation in which multiple apps would be all trying to act as a speakerphone at the same time. Although I suppose you could have more than one bluetooth adapter, and more than one cell phone, and try to carry out more than one conversation at a time

gentoocar

Ok here's something a little confusing... with my motorola V551 I can only connect to my pc when I have the hf "handsfree" service registered and am listening on that channel (6). With my wife's LG something-or-other I can only connect to my pc when I have the hfag "handsfree audio gateway" service registered and am listening on that channel (7). What gives? Which one is correct? Can anybody here with another brand of phone check what you get?

Here's how I'm checking:
- pair your phone up first
- run "sdptool add hf"
- run "sdptool browse local" to see what rfcomm channel it specifies
- run "rfcomm listen hci0 n" where n is that channel
- You will see "Waiting for connection on channel n"
- use your phone to try to connect to your pc as a headset
- If that channel works, you will see
Connection from 00:0A:28:89:4E:65 to /dev/rfcomm0
Press CTRL-C for hangup
Disconnected
- After a moment it will disconnect since nothing is there to reply to it.
- run "sdptool del 0xnnnnnn" where that is the service record you see with "sdptool browse local"
- run "sdptool add hfag" and then repeat the above steps to see if you can connect on that channel.

I'd like to figure out whether this daemon will have to listen on multiple channels, etc. Or whether I'm just doing something dumb.

gentoocar

ok I think I found the problem. I had paired up with my wife's phone a while back, and I think I only had the hfag service registered at that time. After I re-paired, they both work with the hf service. So it looks like the phone saves the channel associations at pairing time. So I guess I only need to listen on one channel.

Zimans

Quick reply, i'll post more in the morning.

An issue I had with my phone (Samsung) is that I could connect to my app from the phone itself, but the phone strangely enough would not let my app dial out. If my app conected to the phone than everything was fine. I never really chased it down as the expected behavior was for my app to connect. I was just connecting with the phone for testing.

--Zims

__________________
--------------------------------------------------------------------------------
Now, Where are my Pants?

gentoocar

Here's some good news...

First, I found THE Handsfree spec. This describes in great detail how everything works. And, yes, we get access to the phonebook, as well as in-band ringtones
http://www.bluetooth.com/NR/rdonlyre...PEC_V10r00.pdf

Second, I made some progress on the re-written app this weekend. It's still in it's infancy, but it can accept as well as initiate connections to a phone (but doesn't do anything with that connection yet). Hopefully within the next few days I'll get the OK to release the utility classes I'm using, then I'll set up a Sourceforge CVS site.

Edit: The part about access to the phonebook and the in-band ringtones actually came from here: http://msdn2.microsoft.com/en-us/library/aa916242.aspx

Alex

daviszr1

I wish that I could help out with this, but I'm still a very newb C++ programmer. Bluetooth is about the last thing to hold me back from making a linux box for the car.

Zimans

The document I linked earlier was for the V1.0 of the HF spec. Thats for 1.5.
The SDP records returned by the phone will tell you if your phone supports 1.5 or not.

Service Name: Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
"Handfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 8
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0100 <-- Verison 1.0, will be 0x0105 for v1.5

Retrieving the phonebook is not part of the Handsfree Profile. It may still work over the rfcomm link, but we may still have to open a second connection to the serial port for phone book entries.

BTW, AT+BRSF=127 is all my phone needs to feel a HF connection is established, good for just plugging random commands for testing.

Despite bluetooth being a standard, every phone behaves a little differently.

--Zims

__________________
--------------------------------------------------------------------------------
Now, Where are my Pants?

MP3Car.com