SPP for binary data using "SPP_Data_Write"

Hi,

SPPLE is not a standard Bluetooth Profile. You will have to make sure the app can use the custom UUIDs that are needed to communicate and read and write to the app.

as you want to send data over BLE, i think you need to use "GATT_Write_Without_Response_Request", Please see the implementation of "SPPLESendData()" function in SPPLEDemo.

Hi Sundeep,

We were assuming that we could use "SPP_Data_Write" which is compatible, at least for sending ASCII, with the android bluetooth terminal app like "blueterm".

A separate problem was that "blueterm" mistranslated binary data being sent to it. But we did  find another "off the shelf"  terminal app for windows 8 that would accept binary. Then we found out "SPP_Data_Write" also had problems with sending binary only data.

Ref for binary compatibly terminal program: http://www.devfor8.com/btterm/ http://www.windowsphone.com/en-us/store/app/bt-terminal/09d679af-bdd8-40b2-b54e-56d68aeb03e0

Are you saying that  when we use "SPP_Data_Write" we are not really using BLE ?  Are you saying that if we want to send binary data using BLE that we should not expect an ordinary  terminal app  to work, but rather we need to  use "GATT_Write_Without_Response_Request"  in our embedded code which is only compatible with a custom app (with a custom UUID)  on the cellphone or tablet side, and it will not work with the terminal progam like the one I provided in the link above ?

-Blue dog.

Correction to previous msg:

The link to the windows 8  bluetooth terminal app that receives binary and nicely translates it into hex is

http://apps.microsoft.com/windows/en-us/app/bluetooth-serial-terminal/b9a0abda-0e28-4b3c-936b-3b9f415fdcdf

- Blue dog.

Hi,

The SPP_Data_Write doesn’t care what data is being sent, it treats all data as a raw byte buffer. We have no issues sending hex only data with the SPP application to BlueTerm. you have mentions that “we can not even pair if all of the data bytes in the packet are binary” but that is before the SPP_Data_Write call, there may be an issue elsewhere.

 Also, the call to SPP_Data_Write is not a LE call. They have to use the GATT calls for LE data transfer.

Hello Sundeep,

Thanks for the additional information. Your comments clarify my understanding about SPP_Data_Write: it "is not a LE (Bluetooth Low Energy) call".

But there is strange and unexpected behavior when we send only binary in that buffer. We use a #define statement to limit what is put in to the buffer from binary: 0-255, to ascii limited bytes: 0-127,     

When the #define is set to allow the full 0-255 range the program malfunctions badly. When the #define is set to limit the bytes to 0-127 the program works great.

I could provide you with either .out files or a zip of my projects, or source files (There are only about 3 of them.) To illustrate what we have. 

Eventually we may want to do this data transfer using LE methods but if we could get it working just with the
original call, that would be a plus. We should also discuss this some more.

Please let us know how to set up  a private conversation with you to give you  the .out files or the  source or the project

Sincerely,

BlueDog, and others.

Hi,

If it is OK with you to share you project, you can share it over the E2E.

Sundeep,

I will share a crucial file that illustrates  our design  issues  and our search for a solution

This file is called SPP_sanSPPLE because, as it stands, in this file  I temporarily commented out some
 of the SPPLE functionality to see what was needed to just use SPP.

Line 2086:    //SPPLEReceiveCreditEvent(DeviceInfo, 0);
Line 2090:    //SPPLEReceiveCreditEvent(DeviceInfo, Value);
Line 2095:  //SPPLEDataIndicationEvent(DeviceInfo, GATT_ServerEventData->Event_Data.GATT_Write_Request_Data->AttributeValueLength, GATT_ServerEventData->Event_Data.GATT_Write_Request_Data->AttributeValue);
Line  2111: //SPPLESendCredits(DeviceInfo, DeviceInfo->ReceiveBuffer.BytesFree);
Line 2189:    //SPPLESendCredits(DeviceInfo, DeviceInfo->ReceiveBuffer.BytesFree);
Line 2231:    //SPPLESendCredits(DeviceInfo, 0);
Line 2236:    //SPPLEReceiveCreditEvent(DeviceInfo, 0);
Line 2754:    //RegisterSPPLE(NULL);

We started out wanting to use SPP because we thought it would be easy for testing.
but it does not work for binary, but it does work when "__ASCII_DUMMY_DATA__" is defined.

This issue is still not solved, BUT THIS IS NOT OUR MAIN ISSUE !

Our real issue is that we need to send 30 bytes of data every 10 mS from an A/D conversion of 3 samples =
6 bytes of data every 2 mS (6x5=30)

We really want do do this using "Low Energy calls"

We finally desire to not use  SPP (high energy),  and are attempting to develop a custom LE profile.

Our approach is to morph or modify the service table as illustrated

At line 424 of this sample file

/*********************************************************************/
/**                     SPPLE Service Table                         **/
/*********************************************************************/
See this in my source file

We are quite uncertain as to how to do this.

One important question in my mind. The profile provided by TI bluetopia in this example was supposed to be
SPP emulation with LE calls.

I think that many of the calls that I commented out (See the start of this post for partial list) have to do with
SPP emulation.

Our problem is we need an explanation as to how exactly SPP works or more importantly if we want to go LE
how does SPP emulation work ?. if we really want to modify SPP emulation for our puposes, Or is it that
 is not what we need to use ?

In our case,  writing a profile from scratch, should we totally remove these calls like "SPPLEReceiveCreditEvent(DeviceInfo, 0)" or "SPPLESendCredits(DeviceInfo, DeviceInfo->ReceiveBuffer.BytesFree)" from our code

Your help and advice is surely needed.

Also what about  the original author of this code, could he help us ?

/*   mm/dd/yy  F. Lastname    Description of Modification                     */
/*   --------  -----------    ------------------------------------------------*/
/*   04/16/12  Tim Cook       Initial creation.

I suppose this is not the Tim Cook the SPPLE author ?

http://en.wikipedia.org/wiki/Tim_Cook

But we sure could use the author of this code's advice about the approach to take !

Best regards,

"Blue Dog"

Attached is the file:

2100.SPP_sansSPPLE.c