RFCOMM packet framing

485 views
Skip to first unread message

Eric Ranstrom

unread,
May 16, 2011, 4:47:13 AM5/16/11
to btstack-dev
Hello,

I am attempting to transmit data from an Arduino Uno using Sparkfun's
BlueSMiRF silver blue tooth module to my ipod touch running btstack.
From the Arduino, I send packets (each packet is an array of uint8_t)
via bluetooth to the ipod. The ipod receives approximately 50% of the
sent packets in their entirety, but only the last several bytes of the
other packets. I have sniffed the bluetooth traffic, and I know that
the packets are being sent from the BlueSMiRF correctly, leading me to
believe that my problem arises from my lack of packet framing.

I have attempted to delve into the btstack source, but as an
inexperienced programmer, I am having difficulty locating where the
incoming data is being assembled into packets. Can anyone suggest how
to go about implementing packet framing for RFCOMM in btstack?
Adding on a few bytes for framing on the Arduino-side is no problem,
but I don't know where to start for btstack.



If it helps answer my question at all, to incorporate btstack in my
ipod application, I used code from rfcomm-cat.c in btstack/examples
I modified the packet handler (only the RFCOMM_DATA_PACKET case) as
shown below. I also wrote a Packet object that is basically a wrapper
for an uint8_t array, with a little other functionality. t refers to
a textArea and g refers to a graphics context for quartz2d.



void packet_handler(uint8_t packet_type, uint16_t channel, uint8_t
*packet, uint16_t size){
bd_addr_t event_addr;
uint16_t mtu;
uint16_t rfcomm_channel_id;

t.text=@"RFCOMM PACKET";

switch (packet_type) {

case RFCOMM_DATA_PACKET:

printf("Received RFCOMM data on channel id %u, size %u\n", channel,
size);
hexdump(packet, size);
Packet *p = [[Packet alloc] init];

[p setPacket:packet];

t.text = [p printPacket:size];
// NSString *s=[NSString stringWithFormat:@"packet size is
%d",size];
// t.text = s;


[g addDataToGraphics:p];
[g setNeedsDisplay];
break;

case HCI_EVENT_PACKET:
switch (packet[0]) {

case BTSTACK_EVENT_POWERON_FAILED:
// handle HCI init failure
printf("HCI Init failed - make sure you have turned off Bluetooth
in the System Settings\n");
exit(1);
break;

case BTSTACK_EVENT_STATE:
// bt stack activated, get started
if (packet[2] == HCI_STATE_WORKING) {
bt_send_cmd(&rfcomm_create_channel, addr, rfcomm_channel);
}
break;

case HCI_EVENT_PIN_CODE_REQUEST:
// inform about pin code request
printf("Using PIN 0000\n");
bt_flip_addr(event_addr, &packet[2]);
bt_send_cmd(&hci_pin_code_request_reply, &event_addr, 4, "0000");
break;

case RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE:
// data: event(8), len(8), status (8), address (48), handle(16),
server channel(8), rfcomm_cid(16), max frame size(16)
if (packet[2]) {
printf("RFCOMM channel open failed, status %u\n", packet[2]);
} else {
rfcomm_channel_id = READ_BT_16(packet, 12);
mtu = READ_BT_16(packet, 14);
printf("RFCOMM channel open succeeded. New RFCOMM Channel ID %u,
max frame size %u\n", rfcomm_channel_id, mtu);
// uint8_t message[] = "Hello World from BTstack!\n";
// bt_send_rfcomm(rfcomm_channel_id, message, sizeof(message));

}
break;

case HCI_EVENT_DISCONNECTION_COMPLETE:
// connection closed -> quit test app
printf("Basebank connection closed\n");
break;

default:
break;
}
break;
default:
break;
}
}

Matthias Ringwald

unread,
May 16, 2011, 6:30:26 AM5/16/11
to btsta...@googlegroups.com
Hi Eric

According to the RFCOMM specification and consistent with the idea of a virtual serial port, RFCOMM doesn't provide any kind of packet/message framing. If you did receive complete messages in other setup, that was good luck :). Please read my rant on RFCOMM here: http://code.google.com/p/btstack/wiki/RFCOMM

Either use L2CAP or do your own message framing.

Best
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>

Daniel J. Peirano

unread,
May 16, 2011, 6:40:47 AM5/16/11
to btsta...@googlegroups.com
I think the issue that Eric is describing is that there seem to be bytes dropped when the RFCOMM is engaged in a burst method.  It can sometimes drop key bytes at the beginning of a "psuedo-packet" when the BlueSMiRF is properly sending them, but the Arduino only sends a "packet" every quarter second.  Full disclosure is that I'm working with Eric on the project that he describes, but I unfortunately have not been dealing with the Bluetooth specific part.  However, though the Arduino is sending out full "packets" every quarter second, and when the BT channel is sniffed, those full packets are there, but BTStack seems to be dropping the first byte of the packet sent every now and then which is making us uncomfortable to move forward with faster speeds. Again, Eric can probably describe the problem in more depth to specifically address your response, but the issue is not packet framing for RFCOMM, but rather burst use of the serial connection, and we're wondering how we're implementing this incorrectly.

Again, Eric should be up in the morning to discuss in depth the concerns we have, but he had a system working fine when we were off RFCOMM, but we had trouble using the WT-32 in conjunction with the Arduino, and since RFCOMM opened up, we transferred over to the BlueSMiRF where we ran into the problem he described above. 

Thank you for all your assistance and advice, as well as for creating BTStack! We wouldn't be able to do this project without your creation.


Daniel J. Peirano

University of California, Davis
College of Engineering
djpe...@ucdavis.edu

djpe...@gmail.com

Message has been deleted

Eric Ranstrom

unread,
May 16, 2011, 12:23:35 PM5/16/11
to btstack-dev
Matthias,

Thank you for your quick response. As Daniel said, we are very
appreciative of your work in creating btstack, without which our
project would be impossible.

I guess my question is this: If I were to implement packet framing for
RFCOMM, where would be the first place to start modifying the btstack
source to detect for the packet delimiters? From my understanding,
the packet handler used in RFCOMM-cat.c is written to handle packets
containing an array of 8 bit unsigned integers. Where does btstack
read the incoming data from the bluetooth serial pipe, and package
this data in to "packets" for the RFCOMM packet handler?

Again, thank you for help and all of your hard work on btstack. I
appreciate it immensely.

Best,
Eric Ranstrom

Matthias Ringwald

unread,
May 16, 2011, 2:49:05 PM5/16/11
to btsta...@googlegroups.com
Hi Daniel (& Eric)

I'll answer Eric's second mail in a minute as you both seem to describe different problems.

First question: how did you "sniff" Bluetooth traffic? Commercial scanners starts at 5k USD and I haven't seen on at ETH Zurich when I was there.

Then, BTstack isn't supposed to loose data, not even single bytes. If you have observed this, please provide me with both the packet log (/tmp/hci_dump.pklg) and the data dumped by  rfcomm-cat.c for comparison.

What size are your "packets" btw (which are sent at 1/4 Hz)?

Best
 Matthias

Matthias Ringwald

unread,
May 16, 2011, 2:58:37 PM5/16/11
to Eric Ranstrom, btstack-dev
Hi Eric (& Daniel)

On 16.05.2011, at 17:57, Eric Ranstrom wrote:

> Matthias,
>
> Thank you for your quick response. As Daniel said, we are very
> appreciative of your work in creating btstack, without which our
> project would be impossible.
>
> I guess my question is this: If I were to implement packet framing for
> RFCOMM, where would be the first place to start modifying the btstack
> source to detect for the packet delimiters?

Short answer: You shouldn't.

Long answer: RFCOMM provides a virtual serial port and packet framing is part of your application on both sides. So, you can come up with a packet format, e.g. sending a single byte length denominator and then adding all data you get in the packet handler until you have all bytes together. You may look at hci_transport_h4.c where HCI packets are read from the Bluetooth module and no assumption is made about in what chunks data arrives.


> From my understanding,
> the packet handler used in RFCOMM-cat.c is written to handle packets
> containing an array of 8 bit unsigned integers. Where does btstack
> read the incoming data from the bluetooth serial pipe,

Your picture is upside down. BTstack receives HCI packets from the Bluetooth module and for those that are part of an RFCOMM exchange, the payload gets delivered to your packet handler.

This problem most likely comes from thwse popular "I learnt how to use an UART and now I want to do Bluetooth, please help me"-Bluetooth chips that emulate a serial port. They decide on segmenting the serial data stream and send RFCOMM packets.

Best
Matthias

> and package
> this data in to "packets" for the RFCOMM packet handler?
>
> Again, thank you for help and all of your hard work on btstack. I
> appreciate it immensely.
>
> Best,
> Eric Ranstrom
>

Eric Ranstrom

unread,
May 20, 2011, 12:16:18 PM5/20/11
to btstack-dev
Matthias,

Thank you again for all of your help.

>First question: how did you "sniff" Bluetooth traffic? Commercial scanners starts at 5k USD and I haven't seen on at ETH Zurich when I was >there.

As for detecting bluetooth traffic sent out by my bluetooth module, I
did this by pairing the device with a bluetooth dongle on my laptop,
and using a terminal program to monitor the traffic on the bluetooth
dongle's COM port. "Sniffing" was not the correct word choice. Sorry
for the confusion.

Currently in my program, I am attempting to send a 64 byte array from
device (Arduino + BlueSMiRF) at approximately 4 Hz. The first number
in the array is the counter (which overflows after 255) and the
remaining numbers are 2 through 64. Every time an RFCOMM_Packet is
read that is not 64 bytes in size, I attempt to send a message
containing [0 1 2 3] from the ipod to the device.

At this point, I should confess that I am very ignorant both about
Bluetooth technology and standards, and electronic communications in
general. I am sorry if I am getting any of this wrong, and I really
appreciate your patience.

To test, I set my Arduino to loop its broadcast, and paired it with my
ipod running btstack. I let the program run for 20 or 30 seconds.
Below is the hci_dump.pklg file.


[17:25:13.232] [RFCr] UIH 58 bytes of data for channel 0x01 [07 08
09 0a 0b 0c 0d 0e 0f 10 ...]
[17:25:13.439] [RFCr] UIH 1 bytes of data for channel 0x01 [f5 ]
[17:25:13.451] [RFCr] UIH 63 bytes of data for channel 0x01 [02 03
04 05 06 07 08 09 0a 0b ...]
[17:25:13.703] [RFCr] UIH 1 bytes of data for channel 0x01 [f6 ]
[17:25:13.710] [RFCr] UIH 63 bytes of data for channel 0x01 [02 03
04 05 06 07 08 09 0a 0b ...]
[17:25:13.961] [RFCr] UIH 4 bytes of data for channel 0x01 [f7 02 03
04 ]
[17:25:13.963] [RFCr] UIH 60 bytes of data for channel 0x01 [05 06
07 08 09 0a 0b 0c 0d 0e ...]
[17:25:14.216] [RFCr] UIH 9 bytes of data for channel 0x01 [f8 02 03
04 05 06 07 08 09 ]
[17:25:14.217] [RFCr] UIH 55 bytes of data for channel 0x01 [0a 0b
0c 0d 0e 0f 10 11 12 13 ...]
[17:25:14.469] [RFCr] UIH 1 bytes of data for channel 0x01 [f9 ]
[17:25:14.471] [RFCr] UIH 63 bytes of data for channel 0x01 [02 03
04 05 06 07 08 09 0a 0b ...]
[17:25:14.726] [RFCr] UIH 4 bytes of data for channel 0x01 [fa 02 03
04 ]
[17:25:14.728] [RFCr] UIH 60 bytes of data for channel 0x01 [05 06
07 08 09 0a 0b 0c 0d 0e ...]
[17:25:14.987] [RFCr] UIH 9 bytes of data for channel 0x01 [fb 02 03
04 05 06 07 08 09 ]
[17:25:14.995] [RFCr] UIH 55 bytes of data for channel 0x01 [0a 0b
0c 0d 0e 0f 10 11 12 13 ...]
[17:25:15.247] [RFCr] UIH 13 bytes of data for channel 0x01 [fc 02
03 04 05 06 07 08 09 0a ...]
[17:25:15.248] [RFCr] UIH 51 bytes of data for channel 0x01 [0e 0f
10 11 12 13 14 15 16 17 ...]
[17:25:15.500] [RFCr] UIH 3 bytes of data for channel 0x01 [fd 02
03 ]
[17:25:15.502] [RFCr] UIH 61 bytes of data for channel 0x01 [04 05
06 07 08 09 0a 0b 0c 0d ...]
[17:25:15.754] [RFCr] UIH 8 bytes of data for channel 0x01 [fe 02 03
04 05 06 07 08 ]
[17:25:15.756] [RFCr] UIH 56 bytes of data for channel 0x01 [09 0a
0b 0c 0d 0e 0f 10 11 12 ...]
[17:25:16.020] [RFCr] UIH 2 bytes of data for channel 0x01 [ff 02 ]
[17:25:16.022] [RFCr] UIH 62 bytes of data for channel 0x01 [03 04
05 06 07 08 09 0a 0b 0c ...]
[17:25:16.274] [RFCr] UIH 4 bytes of data for channel 0x01 [00 02 03
04 ]
[17:25:16.276] [RFCr] UIH 60 bytes of data for channel 0x01 [05 06
07 08 09 0a 0b 0c 0d 0e ...]
[17:25:16.463] [L2Cs] Code: 6 Disconnection Request [Identifier:
0x15 Length: 0x0004]
[17:25:16.463] [HCIe] HCI_Event: 0x66 (Unknown or Log-Unimplemented
Event Type)
[17:25:16.553] [L2Cr] Code: 7 Disconnection Response [Identifier:
0x15 Length: 0x0004]
[17:25:16.553] [HCIe] HCI_Event: 0x71 (Unknown or Log-Unimplemented
Event Type)
[17:25:16.553] [HCIe] HCI_Event: 0x81 (Unknown or Log-Unimplemented
Event Type)
[17:25:16.553] [L2Cs] Code: 6 Disconnection Request [Identifier:
0x16 Length: 0x0004]
[17:25:16.558] [HCIe] HCI_Event: 0x13 (Number of Completed Packets)
[17:25:16.564] [L2Cr] Code: 1 Command reject [Identifier: 0x16
Length: 0x0006]
[17:25:26.464] [HCIe] HCI_Event: 0x60 (Unknown or Log-Unimplemented
Event Type)
[17:25:26.465] [HCIc] HCI_Command: 0x06 - Disconnect
[17:25:26.466] [HCIe] HCI_Event: 0x61 (Unknown or Log-Unimplemented
Event Type)
[17:25:26.468] [HCIe] HCI_Event: 0x0f (Command Status) - Disconnect
- Status: 0
[17:25:26.774] [HCIe] HCI_Event: 0x60 (Unknown or Log-Unimplemented
Event Type)


I then disconnected the device from the ipod (in my program), sshed
into the ipod, and ran the rfcomm-cat program from btstack/example
Below is the textfile produced by rfcomm-cat

Trying connection to 00-06-66-42-AA-CA channel 1
RFCOMM channel open succeeded. New RFCOMM Channel ID 127, max frame
size 0
Received RFCOMM data on channel id 6, size 0

Received RFCOMM data on channel id 6, size 5
AA 02 03 04 05
Received RFCOMM data on channel id 6, size 59
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C
1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
AB
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
AC
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
AD 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 8
AE 02 03 04 05 06 07 08
Received RFCOMM data on channel id 6, size 56
09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
AF
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
B0 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
B1 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
B2
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
B3
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
B4 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
B5
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 20
B6 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14
Received RFCOMM data on channel id 6, size 44
15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B
2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 5
B7 02 03 04 05
Received RFCOMM data on channel id 6, size 59
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C
1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
B8
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
B9 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
BA
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
BB
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
BC
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
BD 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 8
BE 02 03 04 05 06 07 08
Received RFCOMM data on channel id 6, size 56
09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 2
BF 02
Received RFCOMM data on channel id 6, size 62
03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 2
C0 02
Received RFCOMM data on channel id 6, size 62
03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
C1 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C2
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C3
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 10
C4 02 03 04 05 06 07 08 09 0A
Received RFCOMM data on channel id 6, size 54
0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21
22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38
39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C5
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C6
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
C7 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C8
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
C9
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 5
CA 02 03 04 05
Received RFCOMM data on channel id 6, size 59
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C
1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
CB
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
CC
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
CD 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 9
CE 02 03 04 05 06 07 08 09
Received RFCOMM data on channel id 6, size 55
0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
CF
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
D0 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
D1 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D2
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D3
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
D4 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D5
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D6
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
D7 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D8
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
D9
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
DA 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 9
DB 02 03 04 05 06 07 08 09
Received RFCOMM data on channel id 6, size 55
0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
DC
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
DD 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 8
DE 02 03 04 05 06 07 08
Received RFCOMM data on channel id 6, size 56
09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 2
DF 02
Received RFCOMM data on channel id 6, size 62
03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 2
E0 02
Received RFCOMM data on channel id 6, size 62
03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
E1 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E2
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E3
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
E4 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E5
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E6
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 5
E7 02 03 04 05
Received RFCOMM data on channel id 6, size 59
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C
1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E8
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
E9
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
EA 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 8
EB 02 03 04 05 06 07 08
Received RFCOMM data on channel id 6, size 56
09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
EC
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
ED 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
EE 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
EF
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 7
F0 02 03 04 05 06 07
Received RFCOMM data on channel id 6, size 57
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
F1 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
F2
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
F3
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 6
F4 02 03 04 05 06
Received RFCOMM data on channel id 6, size 58
07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
F5
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
F6
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
F7 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 9
F8 02 03 04 05 06 07 08 09
Received RFCOMM data on channel id 6, size 55
0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 1
F9
Received RFCOMM data on channel id 6, size 63
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18
19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 4
FA 02 03 04
Received RFCOMM data on channel id 6, size 60
05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B
1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 9
FB 02 03 04 05 06 07 08 09
Received RFCOMM data on channel id 6, size 55
0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 13
FC 02 03 04 05 06 07 08 09 0A 0B 0C 0D
Received RFCOMM data on channel id 6, size 51
0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24
25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B
3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 3
FD 02 03
Received RFCOMM data on channel id 6, size 61
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 8
FE 02 03 04 05 06 07 08
Received RFCOMM data on channel id 6, size 56
09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 3A 3B 3C 3D 3E 3F 40
Received RFCOMM data on channel id 6, size 2
FF 02
Received RFCOMM data on channel id 6, size 62
03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D



The packet log and the text produced rfcomm-cat seem similar. From
what I can tell through pairing my device with my computer and
monitoring the appropriate COM port, it is sending out 64 byte arrays
(I am using a free com-monitoring program however, and I cannot watch
for very long, so I am not completely certain that I am always
broadcasting perfect arrays).

My goal is to write a 64 byte packet from the arduino, and read a 64
byte packet on the ipod. I know that the mtu which is calculated in
rfcomm-cat is 7 bytes. If I am able to command the BlueSMiRF to up
the mtu to 64 bytes, could I expect a cleaner connection?

Again, I really appreciate all of your help and input. And I
apologize for my ignorance.

Best,
Eric Ranstrom






On May 16, 11:58 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

mungewell

unread,
May 20, 2011, 3:45:50 PM5/20/11
to btstack-dev

> First question: how did you "sniff" Bluetooth traffic? Commercial scanners starts at 5k USD and I haven't seen on at ETH Zurich when I was there.

There is some dubious firmware for particular D-Link dongles which can
make they into a 'Frontline On-Air sniffer', with which you can use
with a small app on the Backtrack LiveCD. Not great, but for small
sessions of sniffing it does work.

Happy Googling,
Simon

Matthias Ringwald

unread,
May 25, 2011, 10:21:43 AM5/25/11
to btsta...@googlegroups.com
Hi Eric

your log file shows that BTstack is receiving all data you're sending over the Arduino's UART connection to the BlueSMiRF module.

Now, you first have to understand the concept of serial communication and then come up with a way to detect the message start and reconstruct your original message. Try talking to your peers or supervisor for this.

Best
Matthias

On 20.05.2011, at 18:16, Eric Ranstrom wrote:

> Matthias,
>

Eric Ranstrom

unread,
May 26, 2011, 3:04:13 AM5/26/11
to btstack-dev
Matthias,

Thank you very much for your help. I am now able to reconstruct my
entire message. I can achieve a transfer rate of approximately 5
kilobytes per second, and above that the application will receive data
for a little while, and then stop suddenly. When I look at the packet
log, it appears that the packets are no longer being sent (or being
received). Does btstack support the 3Mbps data transfer rate that
iphone bluetooth module is supposedly capable of? Is it possible that
a memory leak or otherwise inefficient coding in my iOS code would
affect the Bluetooth connection? (I ask this second question because
I was previously allocating memory in a loop, without subsequently
freeing it, and was unable to achieve a rate higher than 100Bps while
this error existed in my code).

Thank you again for all your help. My application is finally coming
together, and both btstack and your debugging help have been
instrumental in its development.

On May 25, 7:21 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

Matthias Ringwald

unread,
May 26, 2011, 5:12:42 AM5/26/11
to btsta...@googlegroups.com

BTstack uses 921 kbit/s on iOS devices. Celeste achieves 40-50 KB/s for OBEX file transfers on top of RFCOMM. So you should have some headroom for improvements.

Matthias

Reply all
Reply to author
Forward
0 new messages