High Speed Data Transfer Bluetooth RN-41

Wireless & IoT
1

Hello all,

I am having a problem with high refresh rates using the RN-41 bluetooth module, sending from PC through bluetooth dongle, to an RN-41 module connected to a microcontroller.

PC → USB Bluetooth Adapter → (wireless) → RN-41 → Microcontroller

My current settings are:

Baud Rate: 38400 bps

Parity: Odd

For this testing, I temporarily disconnect the microcontroller and simply probe the RX pin of the RN-41 with an oscilloscope. When I send a long sequence of data without any pauses or delays, everything appears to be fine. However, when I set a refresh rate on the PC’s end, I encounter some problems. That is, I encounter problems with I do the following.

PC: Send data bytes → Pause N ms → Repeat

When N = ~50 ms, everything appears to be fine. When probing the RX pin, the serial data sequences are separated by 50 ms and there is pretty uniform spacing between sequences.

However, when I make N = 10 ms, I encounter problems. The spacing between sequences is not uniform. Some pulses are separated by 20ish msec, others a little under this, a little more, some 10 (things are just off, though the baud rate is still maintained).

In my PC program, I basically have send sequences in a while loop, and refresh the while loop with a delay. Now one could argue there is something wrong with my program, and perhaps there is. But note:

  1. When I send a long sequence with no delays (basically no while loop), the RX line simply sends all the data without long quiescent delays.

  2. I tried using a wired RS-232 interface and probed this output. I got pretty uniform spacing and satisfactory results even at refresh rates below 10 ms.

It appears the problem occurs when the bluetooth module is idle, unless I am misinterpretting something. I would appreciate anyone’s comments or suggestions.

Thanks,

Mehdi

2

A couple of reasons this may be happening.

  1. Bluetooth uses a packetised protocol and due to the length of the packets and any retransmits, you will have varying latency.

  2. If you are using 7 bit data mode, the following from the RN41 manual may apply:

Limitations of 7 Bit Data Mode

Roving Networks firmware supports selectable 7 bit data mode, using the “S7,1” command.

Unfortunately the Bluetooth hardware does not support 7 bit data, so this function is accomplished in the

firmware application. While completely functional, the performance in 7 bit mode is less than ideal, because

software emulation is required to make this work. Hence, there is a noticeable latency and character per

second processing limit in this mode. Therefore it is not recommended that this mode be used if the desired

serial baudrate is greater than 9600 baud.

  1. Also read this:

7.4 Optimizing for Latency or Throughput

The firmware automatically must make decisions on when to forward receive data coming into the UART RX

input out the RF link. The default mode is to optimize for throughput. In some cases, especially with

smaller close spaced incoming data packets, the data can get split, with partial packet forwarded and other

data coming later. Unfortunately, Bluetooth has algorithms that can cause significant latency between

packets ( > 10ms) at certain times. If the host protocol expects data to come as contiguous bursts and has

short timeouts, this can cause errors. There is another method of optimization, which will force the radio to

attempt to keep small bursts of data together. In this mode we optimize for latency. To enable this mode,

there is a special debug command. The command is “SQ,16”. This sets the latency bit in the firmware. To

disable this mode. Use the command “SQ,0”. The value of the register can be read with the “GQ”

command, and will read back as HEX, even though it is set as decimal.

3

Hey phish,

Thanks for your reply!

I had tried that optimizing for latency feature before, and it didn’t seem to help much, at least not at these high refresh rates. I tried it again and got the same results. I am not using 7-bit mode, so that part of the datasheet doesn’t apply here.

I did contact Roving Networks, and this is what they had to say:

bluetooth connections involve random delays, the latency is not guaranteed.

(from 1 to 25 ms worst case )

and in this case we have even less control, as we are the RECEIVER of the data, correct?

most likely the bluetooth stack/drivers in your PC are causing this delay, since they are the transmitter.

suggestion:

you might be able to gain more control over the situation by using our RN-USB-X USB bluetooth dongle on the PC side. it uses a USB to serial chip (FTDI ) connected to embedded RN-41 module

I will try a better bluetooth dongle on the PC end and see what happens. But it appears that bluetooth may not be the way to go for this application, or maybe these refresh rates are not possible via a wireless interface. Basically every N milliseconds, I would like to send a packet is data (anywhere from 5-8 bytes) from the PC to the RN-41 and into a microcontroller. N should ideally be around 10 ms, and preferably as low as 5 ms.

In particular, what I am sending is channels of data that are read and processed by the microcontroller.

I would appreciate anyone’s insight on this.

Thanks,

Mehdi