community.st.com

Lopez.Antonio · ‎2018-03-22

Posted on March 22, 2018 at 16:00

SPBT3.0DP2 Tx buffering

Hello,

I'm evaluating the SPBT3.0DP2 as a replacement for an AMBER AMB2300 module, which is used in a RS485 to Bluetooth converter device designed around 2007. This converter is used to communicate an Android mobile phone application with an automation controller. The Android application emulates a serial terminal, behaving like an old Televideo 905 device.

So the automation controller is continuosly sending streams of serial data for presenting it on the terminal, i.e. It is continuosly refreshing a display.

The problem I have is that the SPBT3.0DP2 module seems to buffer the data in big chunks before sending it via the BT radio, causing all kinds of display refreshing problems in the Android application, as some effects like blinking are achieved by alternating visualization fields between blank and not blank characters.

This problem doesn't happen when connecting through an AMBER module, as it seems to not buffer so much data before sending it via the BT radio.

My question is, is there a way to reduce the Tx buffering threshold of the SPBT3.0DP2 module? Or do you have any other suggestion to force the module to send the serial data via BT radio at shorter intervals?

Thank you in advance.

Regards.

https://community.st.com/tags♯/?tags=bluetooth

â€Œ

https://community.st.com/tags♯/?tags=serial%20interface

#serial-interface #bluetooth

Lopez.Antonio · ‎2018-04-03

Posted on April 03, 2018 at 16:10

Hello,

I'm wondering if somebody from ST technical staff could give an answer to this question. I know this module is in NRND status, but I'm planning on making a last buy if I could manage it to work.

Thank you.

francesco rebucci_O · ‎2018-04-18

Posted on April 18, 2018 at 16:35

Hi,

indeed SPBT3.0DP2 module uses big transmit buffers to maximize throughput. If I get correct the application scenario, the solution would be buffering in Android application. You will increase delay, but avoid video refreshing issue.

At SPBT3.0DP2 side one suggestion is to use transmit data chunks of BT SPP packet size (1001 bytes).

Lopez.Antonio · ‎2018-04-19

Posted on April 19, 2018 at 10:40

Thank you for answering, Francesco.

We already tried to implement a delay in the Android application, to mimic the original behaviour of the RS232 connection which had about 1 msec per character refresh rate (at 9600 baud), but unfortunately it didn't solve the problem.

I'm afraid the only solution would be to reduce the transmit buffering level of the SPBT3.0DP2 module.

Do you think it would be possible for ST to provide a new firmware version implementing an AT+AB command for setting the Tx buffering level?

Kind regards.

francesco rebucci_O · ‎2018-04-19

Posted on April 19, 2018 at 18:24

I cannot say if there will be a new firmware version. What is the baudrate you are using over SPBT3.0DP2 UART?

How are you transferring continuous data stream over it?

One suggestion, if UART rate is low, is to insert pauses in the stream. SPBT3.0DP2 detects idle on RX and tries to send bytes received on UART

Lopez.Antonio · ‎2018-04-20

Posted on April 20, 2018 at 09:29

First I want to clarify that the discussion originated talking about Tx buffering level, but now I understand that it is really a serial side Rx buffering level problem.

The automation controller sends data at 9600 baud rate. There is no flow control implemented on its communications port. Whenever it wants to show display effects like blinking, it enters a loop which sends a continuous stream of data. The blinking effect is achived by alternating the affected fields betwen spaces and characters every 0.5 seconds.

This mechanism works fine when connecting the automation controller to a custom programming terminal via a RS232 cable. It also works with the programming terminal emulator running on an Android phone, connecting through a serial/bluetooth converter based on an AMBER AMB2300 module. That's why I think the problem lies in execessive buffering on the serial Rx channel of the SPBT3.0DP2 module.

Unfortunately, I have no chance of modifying the automation controler's firmware, because there is a large base installed and upgrading the firmware in the field would be difficult and costly.

So in the end, my only hope is that ST modifies the SPBT3.0DP2 firmware to provide a new command for setting the buffering level of the serial Rx channel from the module.

Thank you again for your support.

Regards.