SPBT2632C2A with transmission rates >= 114kbps: Lost packages

[avonluehmann9]

Posted on October 12, 2015 at 11:33

I implemented a system with the SPBT2632C2A Bluetooth module and an ATSAM4S Cortex M4 Microcontroller for data transmission.

Using the SPP protocoll for data logging via a virtual com port on win7/8, I spent several weeks now, trying to debug the following problem, amongst others with a unit test: With default UART Baudrate 115,2kBd, the microcontroller sends a byte(10bits) every ~90�s - and thus data with a rate of ~111kBd. Custom data packets are sent including a packet number incremented with each packet. Every now and then (not determined but in the order of several seconds), the received data at the pc shows ''gaps'' in the packet increments that indicate that approximately 8168 bits of data are lost - which is about one bluetooth packet!? Now I would like to know the reasons - and more importantly the possible solutions to solve this issue.

I had expected, that the firmware cares about resending bluetooth packets that got lost or were transmitted faulty.

It seems, that this has to do with the Module's Firmware. Since we want(ed) to use the modules for a product, this issue is a major drawback. Also, we could not find how to change the CPU to High speed mode, as this is neither specified in the Hardware specs datasheet nor the UM1547 AT Command Set Manual. Is the CPU automatically switching modes? Best Regards Alexander von L�hmann, M.Sc.

Further Details:

- No (software/hardware) handshaking is used, however the module's RTS level was monitored and never showed a change - the transmitted data from the �C was also captured with an ftdi-usb chip in parallel to the Bluetooth RXd line - and no packets are lost here. The issue is definitely with the Bluetooth Module - Data is captured with the onboard bluetooth module of a lenovo T440s thinkpad and a Terminal Program (HTerm) or LabView - both showing the same behavior. #spbt2632c2a.-lost-packets

[marchese.graziella]

Posted on October 29, 2015 at 16:27

Sorry dear customer,

but the Low Power RF Solutions forum is exclusively dedicated to Bluetooth Low Energy and Spirit1 devices, thus here you cannot find the right support you deserve.

Regards,

Low Power RF Solutions support team

I implemented a system with the SPBT2632C2A Bluetooth module and an ATSAM4S Cortex M4 Microcontroller for data transmission.

Using the SPP protocoll for data logging via a virtual com port on win7/8, I spent several weeks now, trying to debug the following problem, amongst others with a unit test: With default UART Baudrate 115,2kBd, the microcontroller sends a byte(10bits) every ~90µs - and thus data with a rate of ~111kBd. Custom data packets are sent including a packet number incremented with each packet. Every now and then (not determined but in the order of several seconds), the received data at the pc shows ''gaps'' in the packet increments that indicate that approximately 8168 bits of data are lost - which is about one bluetooth packet!? Now I would like to know the reasons - and more importantly the possible solutions to solve this issue.

I had expected, that the firmware cares about resending bluetooth packets that got lost or were transmitted faulty.

It seems, that this has to do with the Module's Firmware. Since we want(ed) to use the modules for a product, this issue is a major drawback. Also, we could not find how to change the CPU to High speed mode, as this is neither specified in the Hardware specs datasheet nor the UM1547 AT Command Set Manual. Is the CPU automatically switching modes? Best Regards Alexander von Lühmann, M.Sc.

Further Details:

- No (software/hardware) handshaking is used, however the module's RTS level was monitored and never showed a change - the transmitted data from the µC was also captured with an ftdi-usb chip in parallel to the Bluetooth RXd line - and no packets are lost here. The issue is definitely with the Bluetooth Module - Data is captured with the onboard bluetooth module of a lenovo T440s thinkpad and a Terminal Program (HTerm) or LabView - both showing the same behavior.