AT commands not being parsed correctly from Samsung Wave HFP

AT commands not being parsed correctly from Samsung Wave HFP

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Hi all,

He are having some trouble with the Samsung Wave, apparently because the 
AT commands are not being parsed correctly. Here you have the log from 
oFono:

ofonod[12078]: plugins/hfp_hf.c:hfp_enable() 0x1aa8f90
ofonod[12078]: > AT+BRSF=118\r
ofonod[12078]: < \r\n+BRSF: 481\r\n
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CIND=?\r
ofonod[12078]: < \r\n+CIND: 
("call",(0,1)),("callsetup",(0-3)),("service",(0,1)),("signal",(0-5)),("roam",(0,1)),("battchg",(0-5)),("callheld",(0-2))\r\n
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CIND?\r
ofonod[12078]: < \r\n+CIND: 0,0,1,5,0,1,0\r\n
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CMER=3,0,0,1\r
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CHLD=?\r
ofonod[12078]: < \r\n+CHLD: (0,1,1x,2,2x,3,4)\r\n
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: src/modem.c:modem_change_state() old state: 0, new state: 1
ofonod[12078]: plugins/hfp_hf.c:hfp_pre_sim() 0x1aa8f90
ofonod[12078]: drivers/hfpmodem/call-volume.c:hfp_call_volume_probe()
ofonod[12078]: drivers/hfpmodem/handsfree.c:hfp_handsfree_probe()
ofonod[12078]: src/modem.c:modem_change_state() old state: 1, new state: 2
ofonod[12078]: plugins/hfp_hf.c:hfp_post_sim() 0x1aa8f90
ofonod[12078]: src/modem.c:modem_change_state() old state: 2, new state: 3
ofonod[12078]: Service level connection established
ofonod[12078]: > AT+CMEE=1\r
ofonod[12078]: drivers/hfpmodem/call-volume.c:hfp_call_volume_register()
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CLIP=1\r
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CCWA=1\r
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: drivers/hfpmodem/voicecall.c:hfp_voicecall_initialized() 
hfp_voicecall_init: registering to notifications
ofonod[12078]: > AT+CIND?\r
ofonod[12078]: < \r\n+CIND: 0,0,1,5,0,1,0\r\n
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+VGS=7\r
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+VGM=7\r
ofonod[12078]: < \r\nOK\r\n
ofonod[12078]: > AT+CLCC\r
ofonod[12078]: < \r\n\r\nOK\r\n\r\n


It seems that, after the last line, no other AT commands are parsed 
correctly. Any ideas of what's wrong?

Cheers,

Mikel

Re: AT commands not being parsed correctly from Samsung Wave HFP

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

Hi Mikel,

> ofonod[12078]: > AT+CLCC\r
> ofonod[12078]: < \r\n\r\nOK\r\n\r\n
> 
> 

There is an extra set of \r\n at the end of the OK and the gsmv1 syntax
parser used by the hfp_hf plugin is quite strict.

> It seems that, after the last line, no other AT commands are parsed
> correctly. Any ideas of what's wrong?

Try using the permissive syntax parser.

Regards,
-Denis

Re: AT commands not being parsed correctly from Samsung Wave HFP

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hi Denis,

On 10/06/2011 08:02 PM, Denis Kenzior wrote:
> Hi Mikel,
>
>> ofonod[12078]:>  AT+CLCC\r
>> ofonod[12078]:<  \r\n\r\nOK\r\n\r\n
>>
>>
> There is an extra set of \r\n at the end of the OK and the gsmv1 syntax
> parser used by the hfp_hf plugin is quite strict.
>
>> It seems that, after the last line, no other AT commands are parsed
>> correctly. Any ideas of what's wrong?
> Try using the permissive syntax parser.
>
> Regards,
> -Denis

Right, the permissive one works perfectly. The phone has passed all our 
tests.

Now the next question is whether it would make sense to switch the HFP 
plugin to this parser, or this would rather be done selectively.

Which would be the drawbacks of using the permissive parser for all phones?

Regards,
Mikel

Re: AT commands not being parsed correctly from Samsung Wave HFP

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Hi Mikel,

> 
> Right, the permissive one works perfectly. The phone has passed all our
> tests.
> 
> Now the next question is whether it would make sense to switch the HFP
> plugin to this parser, or this would rather be done selectively.
> 

It should be fine to switch to the permissive syntax parser permanently.
 The reason we used gsmv1 are largely historical (permissive did not
exist at the time) and we also wanted to gauge just how broken some HFP
implementations were.

> Which would be the drawbacks of using the permissive parser for all phones?
> 

Permissive has rather limited support for command echo (e.g. ATE1), but
that should not cause any problems with HFP since the spec mandates echo
to be disabled by default.  However, if manufacturers can't get <CR><LF>
terminators right, maybe they also get this part wrong ;)

Regards,
-Denis