community.st.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-22 08:00 AM
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.
‌ #serial-interface #bluetooth- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-04-03 07:10 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-04-18 09:35 AM
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-04-19 03:40 AM
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-04-19 11:24 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-04-20 02:29 AM
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.