What steps will reproduce the problem? 1. packet_handler from rfcomm-cat, global uint16_t rfcomm_channel_id/mtu set in RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE. 2a. C++ application thread using: bt_send_rfcomm(rfcomm_channel_id, , "Hello world", 11); 2b. C++ application thread using: bt_send_rfcomm(rfcomm_channel_id, , lpd8806Buffer.data(), lpd8806Buffer.size());, where lpd8806Buffer.data() is a uint8_t* encoding RGB data in the LPD8806 LED-strip protocol roughly: 0x00(32bits), Green | 0x80(8), Blue | 0x80(8), Red | 0x80(8), ... 0x00(32)

What is the expected output? What do you see instead? From (2a), result on the serial interface is as expected (eg ASCII "Hello world") From (2b), a packet is sent with 0 payload, likely because the first byte is 0x00. If I prepend some ASCII to the message in (2b), I receive everything up to the 1st 0x00 (eg the 1st byte of my transmission).

What version of the product are you using? On what operating system? iPhone 4, iOS 5.0, BTstack/BTdaemon SVN r1640, establishing an RFCOMM connection to an SPP bluetooth module (specifically EGBT-046S).

This turned out to be a bug in my application code (which BTstack's use of PacketLogger made much easier to debug). My RGB data was not updated correctly on ARM devices, and hexdump inspection of the payload data identified this as my error.

BTstack RFcomm works splendidly now.

hi. thanks for double checking. bt_send_rfcomm is used by Celeste and I've transferred several hundreds of megabytes with it, so it should really work. :)