Baud rates for stable Bluetooth serial communication

Question

I have an Arduino mega communicating over Bluetooth (bluesmirf gold device) to a C# application that I wrote. The Arduino is constantly sending a serial signal of 32 characters, the first always being an "S" and the last an "E". Using putty I can confirm that this signal is being sent correctly 99% of the time.

Now I want to read this signal with my C# application, which I am doing with the following code:

    public string receiveCommandHC()
    {
        
        string messageHC = "";
        if (serialHC.IsOpen)
        {

            while (serialHC.ReadChar() != 'S')
            {

            }
            messageHC = serialHC.ReadTo("E");
            serialHC.DiscardInBuffer();
        }
        return messageHC;
         
    }

serialHC is of the serial class.

Sometimes this works perfectly but other times I'm having problems, I cannot find out why it works sometimes but others not.

The problem that I seem to be having is that sometimes I get a rather large Lag in the data that I am reading from the arduino. I notice this because I am sending button states and they only change a few seconds after I actually press or release the button on the Arduino. I used the standard baud rate of the Bluetooth device, which is 115200, and was wondering if changing that to a much lower rate could yield better results? What if any advantage would that have? I do not need hight communication rates, even updating the state 4-5 times a second would be acceptable for my application.

Is it possible the lag is coming from my code? I think it may be from the while loop that is waiting for the incoming "S" but then I don't see why it should hang there since there are new signals always coming in at a high rate.

I'm using the DiscardInBuffer() because I do not care about outdated data and just want to skip over that. It is much more important that I am reading current up to date data and acting on that fresh data.

Thank you for your help!

Best regards,

Bender

Update:

Just found out a bit more information while debugging. The problem only seems to appear:

When connected over Bluetooth (over USB cable there is absolutely NO Lag)
When a second Bluetooth connection is established from the PC to another device (different COM port and different baud rate)

Does anybody have any experience running two different devices off the same Bluetooth dongle on the PC? I can manage to connect to both no problem but still having the lag issue mentioned before.

Thanks for any help

What are you using to trigger the call to receiveCommandHC()? Its likely that this loop is recieving the command fine, but the next few incomming msgs are being buffered by serialport during that delay. With the oldest msg being read first, and the newer ones discarded. One quick debugging experiment would be to comment out the discard, just to verify if newer msgs are the ones being discarded. I would keep the same baud rate for now. — jdh
Hi, thank you for your response, I am using a timer that triggers every 50ms to read the incomming data. — Bender
Odd are that the SerialPort is sending a DTR signal when opening the port. Set this explicitly to false. — leppie
@leppie Sorry mate, im not quite sure what you are trying to tell me here? — Bender

Hans Passant Hans Passant · Accepted Answer · 2012-02-02T13:41:42

You are not really using a physical serial port here. The BlueTooth driver merely emulates one. This is common, the Windows API has a well defined set of api functions to talk to a serial port. Emulating one makes the interface to the driver simple, the vendor doesn't have to supply an interface DLL or document a complicated DeviceIoControl() protocol.

Which means for one thing that the actual communication settings don't matter. Baudrate is meaningless in this scenario, it is the BlueTooth radio signaling that sets the transfer rate. The driver will accept whatever you select but will otherwise ignore it. Handshake signals might be interpreted, it's up to the driver to implement them. Communication error reporting is very rarely implemented, BlueTooth has an error correcting protocol, unlike a real serial port.

No, the loss of data here is entirely self induced. Clearly the driver does implement DiscardInBuffer(). Which accomplishes nothing but throw away any data that the driver received. This goes wrong if your code runs a bit late or gets interrupted by a thread context switch.

Delete the DiscardInBuffer() call.

Baud rates for stable Bluetooth serial communication

1 Answers