Nokia 6600 bluetooth RecvOneOrMore(..) needs a .15 sec delay
| Thu, 2004-01-15 02:51 | |
|
Hi,
I noticed my bluetooth Data receive code needs a delay of .15 sec before RecvOneOrMore(..) call in Nokia 6600. I call Receive from my RunL(..). Such delays where not needed in 3650 and 7650. If i dont give this delay RecvOneOrMore status returns an error! for the next recv. Why this. Because of this delay my bluetooth receive using 6600 is only 50% fast as 3650!. Is there some reason for this. Looks like this delay is needed by 6600 to complete the previous receive!! But then why is the return status KErrNone the first recv if it dint complete it? But adding this small delay everything seem to work well!! But this is not acceptable as the transfer rate is only 50% of 3650. I would appreciate anyone who can throw more light in to this. void CSocket::Receive(TDes8& aText) { if (!IsActive()) { TSockXfrLength reslen(0); AppUi->StartCommTimer(6,CWideRayBTAppUi::EReceiveFailed); { if(AppUi->Model == NOKIA6600_DEVICE) { RTimer timer; TRequestStatus timerStatus; // request status associated with timer timer.CreateLocal(); timer.After(timerStatus,150000); // .15 sec wait User::WaitForRequest(timerStatus); } sock.RecvOneOrMore(aText,0,iStatus,reslen); } SetActive(); } } Thanks murali |
|






Forum posts: 109
this is strange! However I have kind of the opposite problem on the 7610 which is also a 7.0s device. When my RunL of the Bluetooth receiver does last too long due to logging I have problems:
3 Log's withing the RunL: After 25 Mins of working i get a "System Error" dialog and no other bt request does work, even outside my app until I reboot.
7 Log's withing the RunL: At the fifth part of data arriving, i get -36 KErrDiskFull and after a reconnect, the whole thing runs again for fife reads.
What do you thing about this?
best Regards, Marcel
Forum posts: 100
TSockXfrLength reslen(0);
is declared locally is the culprit? Make it a member variable, and probably delay is not needed?
Forum posts: 21
Forum posts: 28
I noticed that too. Previously i was doing some heavy file i/o and some animation at the background. This makes the bluetooth stack to crash. Hence i removed any extensive background task when doing bleutooth io. This solved the problem. So far i havent found a way out of this.
thanks
murali
Forum posts: 109
i can well support your opinion.
The problem seems to be related to file i/o and not to general tasks within the application process. I have inserted User::After()'s and when I activate them from the app menu, the app is "frozen" for this time, but the bt data rushes in after this. No bt data is lost!
But it seems to be critical that the RunL() from the RecvOneOrMore call is *very* responsive.
br, Marcel