Hi all, I am new to objective-c and mostly have experience in COBOL and Java.
As part of my internship project I have to connect a Mac computer with a custom build device over bluetooth.
All commands are sent through a bi-directional serial connection.
(9600 baud, 8 bit, no parity, no handshake)

The documentation on bluetooth was rather sparse but I did manage to get the devices to pair.
The most useful example I copied and tweaked as needed I found here.

On the Mac I am receiving data from the other device but it splits up the data incorrectly.
For instance when the state of the device changes it sends the following command over bluetooth:
w31CRLF, where w stands for state change and 31 are the parameters and CRLF is a Carriage Return followed by a LineFeed.

When I log the incoming data using the rfcommChannelData delegate method it only takes the alphanumeric value and logs the numerical + Carriage return separately, following by the LineFeed as in the following output in the console:

What makes you so sure the device is not sending the string split as you see it receiving? Or perhaps this is simply timing: the Mac layer may split based on time. Can you not simply accumulate the string until the CRLF terminator is seen?

What makes you so sure the device is not sending the string split as you see it receiving? Or perhaps this is simply timing: the Mac layer may split based on time. Can you not simply accumulate the string until the CRLF terminator is seen?

When I pair the device with my macbook and look for incoming commands by using the screen command in a terminal window I get the command without any splitting up.

Accumulating the string until the CRLF terminator is seen is an option but I was hoping for a more "elegant" solution.

Is there a way to determine if it is a timing issue and if so, is there a way to influence that timing?

Erm the screen command is probably just echoing exactly what comes in.

So if it receives two data packets only one of which has a CRLF at the end this will get printed on the same line. So this does not prove that there is any different behavior from what you are seeing. Essentially it's doing the accumulation on screen...

Unless you can alter the time the Bluetooth stack waits for more data before passing that to you there is no way. Given a long enough string before CRLF you'd always see this so the correct answer is for you to accumulate and split on CRLF.