Page 4 of 13 FirstFirst 12345678910111213 LastLast
Results 31 to 40 of 122

Thread: bluetooth woes

  1. #31
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    How bout Bluez Handsfree Service (BzHFS)? Linux Handsfree?

  2. #32
    Newbie Zimans's Avatar
    Join Date
    Jan 2006
    Posts
    38
    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?

  3. #33
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Quote Originally Posted by Zimans View Post
    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
    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.

  4. #34
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,560
    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
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  5. #35
    Maximum Bitrate nasa's Avatar
    Join Date
    Aug 2006
    Location
    PA
    Posts
    721
    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

  6. #36
    Maximum Bitrate nasa's Avatar
    Join Date
    Aug 2006
    Location
    PA
    Posts
    721


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

    Your only refering to the frontend

    Nasa

  7. #37
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Yes, java for my frontend, the daemon will be written in C++.

  8. #38
    Newbie Zimans's Avatar
    Join Date
    Jan 2006
    Posts
    38
    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?

  9. #39
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Quote Originally Posted by Zimans View Post
    So a daemon huh. I'd suggest using sockets over pipes (Unless that is what you meant), be it UNIX-sockets or tcp/udp.
    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.

    Quote Originally Posted by Zimans View Post
    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.
    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.

    Quote Originally Posted by Zimans View Post
    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?
    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.


    Quote Originally Posted by Zimans View Post
    Is this something that has to be able to handle multiple apps trying to access it?
    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

  10. #40
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    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.

Similar Threads

  1. Bluetooth woes!
    By daveg360 in forum Wireless Communications
    Replies: 1
    Last Post: 10-01-2005, 11:11 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •