Getting bluetooth data without event?

[OneEng]

Hi Mike,

We are accessing the wcl from Java with a DLL wrapper (the DLL being where the wcl is used).

The RX event does not trigger right away like it does in a stand alone app.

Is there any way to poll the data received without waiting for the event?

OR,  is there any way to make the event trigger properly (like a sync method)?

Thanks!

[Mike Petrichenko]

Hi

TwclSyncClient should help. Take a look on SyncClientDemo app.

[OneEng]

Thank you Mike, we will give this a try today.

[Mike Petrichenko]

You are very welcome

[OneEng]

Hi Mike,

Using the wclSyncClient, I implemented the following code:

//---------------------------------------------------------------------------

void __fastcall TMTSBTTool::SendOncePollBtnClick(TObject *Sender)
{
   int Res;
   char *msg, *rxMsg;
   msg = new char[16];
   rxMsg = new char[1000];
   WORD CS;
   unsigned int iBytesToRead, iReadTimeout;


   msg[0]='i';
   msg[1]='7';
   msg[2]=0x0C;
   msg[3]=0;
   msg[4]=0;
   msg[5]=0;
   msg[6]=0;
   msg[7]=0;
   msg[8]=0;
   msg[9]=0;
   msg[10]=0;
   msg[11]=0;
   msg[12]=0;
   msg[13]=0;
   msg[14]=0x0C;
   msg[15]=0;

   DisplayMessageBytes("TX",msg,16);

   Application->ProcessMessages();
   iStartTime = timeGetTime();
   iMsgByteCount = 0; // reset global variable
   iBytesToRead=1;
   iReadTimeout = 1000;
   wclSyncClient->Write(msg, (unsigned int)16);

   // wait for response

   while (iMsgByteCount<16 && iMsgByteCount<1000)
   {
      if (wclSyncClient->DataAvailable)
      {
         Res = wclSyncClient->Read(rxMsg,iBytesToRead,iReadTimeout);
         if (Res == WCL_E_SUCCESS)
         {
            MsgBuffer[iMsgByteCount]=rxMsg[0];
            Sleep(0);
            iMsgByteCount=iMsgByteCount+iBytesToRead;
         }
         else
         {
            LstBx->Items->Insert(0,"Read Error = "+String(Res));
         }
      }
      else
         iEndTime=iEndTime;
   }
   iEndTime = timeGetTime();
   LstBx->Items->Insert(0,"Data Size = "+String(wclSyncClient->DataSize));
   DisplayMessageBytes("RX",MsgBuffer,16);
   LstBx->Items->Insert(0,"Ping Latency = "+String(iEndTime-iStartTime));
   wclSyncClient->DataSize;

   delete[] msg;
   delete[] rxMsg;

}

The first read shows a good reply for the message I sent to our bluetooth device.  All subsequent sends result in garbage.

I noticed that the DataSize value property in the wclSyncClient increases with each write.  It almost seems like the act of reading the client does not clear out the contents from the last read, but I could be mistaken.  I have attached a screen shot showing the progression when the send button is pressed several times.

Am I doing something wrong?

[attachment deleted by admin]

[Mike Petrichenko]

Hi

Add global flag

bool fProcessing = false;

Change your procedure a little bit

void __fastcall TMTSBTTool::SendOncePollBtnClick(TObject *Sender)
{
  if (fProcessing) return;
   fProcessing = true;
   int Res;
.....
  delete[] rxMsg;
  fProcessing = false;
}

That shoudl help

[OneEng]

Thanks again for the prompt reply.

The procedure is a button click.  Each line in the screen shot resulted from a single button click.  The individual button clicks were several seconds apart.  The procedure is not re-entrant, but rather sends a set of bytes to our bluetooth device and waits for the reply.  The first reply is what I expect to see.  All subsequent replies are not what I expect to see.

The first send has latency of 20mSec (about what I expect).  All the other messages have latency of 0 or 1 millisecond leading me to believe that the reply is not actually being captured, but rather that the data available flag is still set resulting in garbage being put into the reply array (which is a global array declared in the form object and memory is allocated in the form create event.

Should the act of reading the bytes also erase them from the buffer?  I would think so, but it doesn't appear to do so.

I have also tried reading the entire message in one read (setting bytes to read = 16).  This also doesn't appear to work.

Any advice would be appreciated.  I will fiddle around more today with it.

[OneEng]

I got it Mike,

I was not reading enough bytes.  The reply is 49 bytes long so I was always leaving stuff behind in the buffer that had not been read yet.

Thanks for your help.

[Mike Petrichenko]

The code I added just protects from clicking button when answer has not been received yet.

With regards to an amount of data available. wclSyncClient has DataSize property so you can check how many bytes are in buffer ready for reading.

[OneEng]

Thanks Mike.

We got it all working.