iban

Hi!
So now a days i still lose my sco audio connection. Gentoocar said it was normal but is there any way to solve it? After reading part of the software i though that "houston we was connected " should appear.
The worst thing is that i make a phone call to my mobile phone a i get a Segmentation Fault and my sound system does not work any more.

About the coding audio after asking to Simon Vogl (author of the handsfree) i definitely agree with you to use S16_LE. I also asked about the pipe to the author and he replied "The missing pipe should raise an error but not cause any other trouble (you can replace it by ctrl=0 to set it to stdin it is used for controlling behavior only "

So basically we really do not have to worry about that.
Any suggestion what to do?

MP3Car.com

 

OLAS

I hacked the handsfree.c code a little and stopped the sco audio connection from cutting out -- or sleeping. Unfortunately this caused a kernel oops.

After a reboot and another execution, the application never got to the code section I edited.

I may be wrong here, but it could be the case that different mobiles/cells output different integer codes for what status they are at (I assume this is GSM codes?) For instance, my Motorola Razr gives 6,3 for when the call is trying to connect, so I changed the if(which == 1 && what ==3) to 6 & 3.

After this, every outbound call I made was transmitted to the speakers. Regular Seg. faults occurred, and with me not being much of a C coder, I couldn't pin down exactly what went wrong. I'm guessing too much data is being sent to the buffer/sound card.

I've since realised that everyone on this thread and I have different goals - I was looking for the opposite thing! I wanted to have incoming calls via Skype/X-Ten/etc directed to my phone... i.e Use the actual handset as a headset. From what I've read so far, I don't think this is possible, unless the bluetooth stack on the phone has the headset profile... and I doubt that it does or it can be added easily.

For the guys making a go of this; I'd check out the source for either or both chan_bluetooth and chan_cellphone from the Asterisk. Both of these modules work very nicely. To speed up development, you could fork either if the licence permits.

I'll still check this thread and offer as much help as I can.

Best of luck.

gentoocar

Hmm, looks like my phone uses handsfree version 1.1 (0x0101), and headset version 1.0. And my bluetooth dongle uses handsfree version 1.1 as well.

So I guess I'll use the 1.0 spec. I'm not sure what has changed between the two but I assume 1.5 devices are backwards compatible. So far in my reading everything looks the same.

BTW my dongle is a Zonet, with a Broadcom "BCM92045DG Non-UHE" chipset.

gentoocar

Ah, I tried that with my phone and the BRSF command alone didn't make it "connected", so I plugged in the rest of the commands from the spec ("AT+BRSF=0", "AT+CIND=?", "AT+CIND?", "AT+CMER=3,0,0,1") and that does the trick for me.

Looks like I have some more spec-reading and parser-writing ahead of me, but I feel like I'm making progress

Zimans

It seems that 1.5 adds more status type of information. For example, roaming/not roaming, signal strength, battery level, etc. However, I believe you can get alot of this information through the serial port, or may be able to atleast. There are at commands to retrieve this. 1.5 also provides a mechanism to retrieve current cell carrier.

1.5 has more options in the CIND response, so make sure you parse it properly (No assumptions :P)

The basic call control seems to be un-changed.

--Zims

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

gentoocar

Well, I'm confused here. My phone reports handsfree version 0x0101 in it's SDP record. So it's not 1.0 and it's not 1.5, I assume they mean 1.1, but I can't find a spec for version 1.1 anywhere, only 1.0 and 1.5. And my phone does give me it's signal strength through +CIEV messages. So I wonder if Motorola used a draft version of 1.5 or something when they made my phone. I'll have to check my wife's phone tonight.

For now I will use the 1.5 spec and will be very careful in parsing. I have no idea how common 1.0 vs 1.5 profile versions are, so when this is done and working, we'll see if anybody is left out wrt the new indicator goodies, and go from there.

Zimans

1.0 and 1.1 seem to essentially be synonymous. If you look in the spec sheet that i posted, it says 1.0, but in the section for the spd records it shows 0x0101 or 1.1.

--Zims

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

gentoocar

Ok, I see it now. So I guess I have 1.0, but motorola included the signal strength indicator as a goody... I won't complain. But I see that I don't have the battery status indicator. Not that the battery status is accurate in these damn motos anyway

MP3Car.com

 

nasa

Finally got around to trying to get this to work,

So I was following TimeKillers steps in post #4, when I can across this command "./handsfree". What program/package is being compiled to get this? I don't see it in the bluez-utils package (using debian).

Thanks

Nasa

OLAS

It's has been replaced by the bluetooth[-dev] package - on Ubuntu anyway.

You may also need to create/copy an older linux/config.h file to your current kernel headers as I think the source requires it, and it has now been depreciated for linux/autoconf.h

gentoocar

ok well I've completed the +BRSF, +CIEV, and +CIND parsers (in great depth, lots of error checking). I'm adding methods to retrieve the signal strength, battery, etc. Next will be call management (ringing, pickup, hangup, dial, etc), and then finally SCO audio.

It's slow progress, but it's coming along.

BTW I checked my wife's phone and she has 1.0/1.1 but it gives battery charge status as an indicator. I will be getting a new phone on tuesday (a sony ericsson, my motorola won hold a charge) so that will be one more phone I get to test with.

Alex

gentoocar

Got a little problem...

Some of the phone responses are two lines. For example, after sending AT+CIND=? the phone sends back a +CIND line, and then an OK line.

My motorola would send back everything at once (i.e. "+CIND....\r\nOK\r\n"). My new ericsson, however, sends the +CIND line, then later on sends the OK line (need two separate reads). So I suppose instead of splitting the response into lines and reading all of them I have to loop and keep reading until I get an OK or an ERROR.

The thing I wonder is can I be sure that I will get the whole line in one read? Is it possible that I could get half a line in one read, and then a moment later get the other half of the line? Or is it all buffered for me at a lower protocol level so that I don't need to worry about that?

gentoocar

some sony ericsson goodies:

I have the following extra indicators that I did not see in the spec anywhere:
"batterywarning", "chargerconnected", "sounder", and "message". Each of these is a boolean (0-1). I assume "message" means there is a new SMS message (since there is already a "voice mail" indicator). I have no idea what "sounder" means. Anyways, I will add support for "batterywarning" and "chargerconnected" since they are easy. I'll try to figure out what the other ones do.

Unfortunately, although my phone reports all these indicators as supported and even gives me their values when I do "AT+CIND?", it does NOT send me +CIEV messages. I did "AT+CMER=3,0,0,1" and it sends me back "OK", but still doesn't give me +CIEV's. Both the moto and the LG I tested with do.

Anyone have any idea why that is?

Zimans

You should buffer. Most likely you will get at least one line all at once, but buffering is the safe way to handle it.

The way I handle response codes is I basically look for OK or ERROR before continuing onto the next command. + codes are handled seperate (As they are un-solicited). At some point I'm going to change the code to move to a command stack vs States. (Thus reducing the number of states that I have)


Do you mean that when you start a call or the phone rings it doesn't send +CIEV ?, or do you mean that it doesn't send any +CIEV messages after you send other commands? It should only send +CIEV's when states change, such as the phone starts to ring, or service is lost, etc.

--Zims

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

gentoocar

Yup. Although + codes have an OK or ERROR if they are responses, just to be confusing


OK, after a little more testing I see that I DO get +CIEV's for call, callsetup, sounder, and message, but NOT for battchg or signal (I left my phone connected overnight so that the battery state did change from 5 to 4, but no CIEV for it).

I would think that if the phone says it supports certain indicators (and gives you the correct values when you send an AT+CIND?) that it would send you CIEV's for them. I suppose a crude hack for this would be to poll for signal strength and battery every second or so, and as soon as I receive a CIEV for them then stop polling. Or I could look into getting that info from a different profile (but are all phones that support handsfree guaranteed to provide a dial-up networking or generic serial port profile?) And what bugs me is that I have no way of knowing programatically which phones have busted signal indicators and which don't, so I guess I'd want to do that for everyone.

MP3Car.com