General
What is a Bluetooth® profile?
Quote from the Bluetooth® SIG;
“Bluetooth® profiles are general behaviors through which Bluetooth® enabled devices communicate with other devices. Bluetooth® technology defines a wide range of profiles that describe many different types of use cases. By following a guidance provided in Bluetooth® specifications, developers can create applications to work with other devices also conforming to the Bluetooth® specification.”
Learn more about Bluetooth® at www.bluetooth.org
Will my Bluetooth® enabled device work with Free2move Bluetooth® modules?
Yes, if both ends share the same Bluetooth® profile.
How do I qualify and list my Bluetooth® product based on Free2move Bluetooth® modules?
You will have to become a adopter member (free of charge) at www.bluetooth.org and list your product based on our end qualified Bluetooth® modules.
Advanced
How can I reduce the latency?
The main problem with Bluetooth® is that it introduces an initial latency of ~25-40ms for the first packet sent in each direction of the continuous data stream. When using a communication protocol where short bursts of data in sent in each direction and waiting for responses before sending the next burst etc (what I call an ACK/NACK protocol) it will have bad performance due to the initial latency.
The initial latency consists of that the microprocessor in the F2M03 must create a Bluetooth® air packet containing serial data that will be parsed through a quite extensive Bluetooth® protocol stack before the message is actually sent out by the radio on the air interface. The receiving radio at the other end sends this message back to the microprocessor that must parse this message through the Bluetooth® protocol stack again to be able to decode and extract the serial data that should be sent out to the serial interface. The initial latency is quite natural when you think of it compared to using a cable. You have a microprocessor at each end and a new transmission medium (air) and this requires extensive baseband software and protocol stack. Also note that the UART data is transmitted two times on the UART interface when replacing the serial cable wireless. One time at the transmitting end and one time on the receiving end.
As mentioned, the initial latency only occurs on the first packet of the data stream sent in one direction. If there’s a continuous data stream applied, the rest of the packets will flow continuously. If the data stream stop then the next time data is sent the first packet will suffer from the initial latency.
In your case you do not have a continuous data stream. You are sending one “command” to your embedded system and it sends a “reply” back. Both packets sent in each direction will suffer from the initial latency “problem”. This is what we call ACK/NACK or REQUEST/RESPONSE protocol. These kinds of communication protocol where short bursts of data in sent in each direction and waiting for responses before sending the next burst etc. will have bad performance when using the Bluetooth® technology (and probably any other wireless technology).
You could always analyze your communication protocol to see if it’s possible to rewrite it to avoid the ACK/NACK. This will give better response time (due to reduced amount of initial latency) but there is always risk of data being segmented.
Increasing the UART baud rate will reduce the UART latency (which is times 2) and speed up the system as well.
But if we just focus on reducing the initial latency in case when you do not want to increase the baud rate. This can be done by fine-tuning parameters in the Wireless UART firmware at the cost of higher current consumption.
1. Start the configuration software and select “Configuration->Show advanced settings…” from the menu.
2. Answer “Yes”.
3. Go to the “Other” page and locate “Performance” square down right.
4. “Optimize device for” select “Latency”.
5. “Quality of service mode” select “Guaranteed”.
6. “Latency (1-1000000 microseconds)” set “10000″.
Note: By switching to “latency” mode and changing the “quality of service” parameters there is an even greater risk that data will break up into several segments if you do not increase the baud rate. But the initial latency is reduced.
If packet segmentation and latency problems is unavoidable it seems like this product is not good for the ACK/NACK protocol that we need to use. Is that true?
This implies for any wireless solution rather than just our Bluetooth® products. You will get the exact same behavior if you try one of our competitors products. Keep in mind that by just replacing a serial cable wireless you have introduced a latency twice as long as with direct cable due to UART data being transmitted twice. Then you will always have some latency introduced into the system by the wireless technology.
It is not unavoidable, you’ll always have the possibility to make modifications to adopt to the new behavior when using a wireless technology compared to using a cable.