×

Discussion Board

Results 1 to 6 of 6
  1. #1
    Registered User
    Join Date
    Sep 2004
    Posts
    10

    Question Bluetooth using RSocket - sending data

    Hello,

    I use the following function for sending data over Bluetooth: void Send(const TDesC8& aDesc,TUint someFlags,TRequestStatus& aStatus,TSockXfrLength& aLen);

    It works just fine: aLen always have the sent length (but you should not delete the aDesc until the RunL is called), except the situations when I try sending 100 times 10 kB buffers very fast. Then on some point the Bluetooth is simply stuck - no event comes that the data is sent. And on recieving side one can see, that data was sent only partially. And nothing happens. Interesting is that when I disconnect from the recieving side, phone does recieve the Disconnect event! :-| This is a complete mistery now: when I put a 100 ms timeout with User::After(100), then I can send this data - but this is not a good solution.

    What I think is there buffer overflow appears in bluetooth controller on the phone. And bluetooth transmitter stops workin, or something like that. And RunL function is being called before the data was physically sent - this is not good at all!!!

    So, how can I avoid this kind of behaviour? Are there any HCI or some low-level protocol commands to verify is transmitting buffer empty or not?

    Thank you in advance,
    Vigen

  2. #2
    Registered User
    Join Date
    May 2003
    Posts
    16

    Me too!

    I have seen the same behavior on two different phone models, both from the same manufacturer (I won't give their name). The only solution I found was the same as yours: User::After(). However, I was able to get by with a wait of only 20 milliseconds instead of 100.

    During my debugging, the problem seemed to be that once BT encountered the problem (in the Send()), it never changed the I/O status; it was always reported as "pending" and it never completed. I believe that you found the same behavior.

    That's all I can add.

  3. #3
    Registered User
    Join Date
    Sep 2004
    Posts
    10
    Nokia has officialy responded in one post on this forum, that there's a problem with RFCOMM protocol on 6600 and 6630 phones (or on Series 60 - not sure, but theses phones are for sure). The problem is that RFCOMM cannot send over 512 bytes at a time on these phones (I guess, they were talking about RSocket::Write(...) function), and he adviced using L2CAP.

    Now I use L2CAP and I can send 672 bytes at a time, but this amount comes from here:
    iSocket.GetOpt(KL2CAPGetOutboundMTU, KSolBtL2CAP, KMaxTransmitMtu); //iSocket must be connected over L2CAP protocol to some device
    After call KMaxTransmitMtu = 672 bytes. And after every Write(...) call, when I get the iStatus (in RunL or after User::WaitForRequest), I can be sure, that I've sent 672 bytes of data.

    Good luck.
    Vigen

  4. #4
    Regular Contributor
    Join Date
    Aug 2004
    Posts
    295

    Re: Bluetooth using RSocket - sending data

    This bug seems to be related to RFCOMM credit based flow control. When one uses Socket.Write when credits are low, the low level bluetooth driver seems to get stuck. This can be fixed by monitoring the credit count, and only send when there are "plenty" credits left.

    This problems occurs at least in 6630 and 7610.

    Following work-around seems to fix the prob:

    Code:
    	while (1)
    		{
    		TInt credit;
    		iSocket.GetOpt(KRFCOMMGetTransmitCredit,  KSolBtRFCOMM, credit);
    		if (credit > 10)
    			{
    			break;			
    			}
    		User::After(200);
    		}
            iSocket.Write(aData, iStatus);

  5. #5
    Regular Contributor
    Join Date
    Aug 2004
    Posts
    295

    Re: Bluetooth using RSocket - sending data

    followup: this bug seems to be triggered when using big buffer in Write (over 6kb seems to cause buggage). 2-4 kb should be ok.

  6. #6
    Registered User
    Join Date
    Oct 2003
    Posts
    23

    Re: Bluetooth using RSocket - sending data

    No, this have happened also with small buffers too.

Posting Permissions

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