bug in serial port communication

Question

Hi! I might just have the weirdest bug you've heard today.

I have this one (very long) method inside a thread, which sends formatted data to a RS232 Led Display.

It should display something like this

TITLE
SUBTITLE 1
ELEMENT 1
ELEMENT 2
SUBTITLE 2
ELEMENT 1
ELEMENT 2
ELEMENT 3

well, each one on it's own message.

I'm calling Thread.Sleep(N) after each one of the messages (so each message is displayed N time).

• N being the number of seconds

Ok, everything is fine until now. The thing is that if (10 <= N <= 20) I get the following output:

TITLE
TITLE
TITLE
TITLE
TITLE
TITLE
TITLE
TITLE

I can hear the beep when I send the message. I even installed a serial port monitor, to check if the information I was sending was the same.

So just to summarize:

Writing on Serial Port works after sleeping the thread for n <= 9 or n >= 20. Anything in between will produce an erroneous output, like if the output was cached or something

What can this be?

Update

• Ok, I know System.Threading.Sleep takes miliseconds as arguments. just multiply the number by 1000.
• Whenever the led display receives a new well formatted message, it beeps. I should have clarified that.

Here is a snippet (this sends the first title)

            using (var ld = new LedScreen(COM))
            {                    
                ld.AddEffect(LedScreen.Effects.Snow);
                ld.AddText(LedScreen.Colors.Red, titulos[ThreadControl.Fase]);
                ld.AddEffect(LedScreen.Effects.DSnow);
                ld.Write();
            }

            //Console.WriteLine(titulos[ThreadControl.Fase]);
            //esperamos N tiempo (titulo)
            Thread.Sleep(TiempoTitulo);

I wrote the LedScreen class. The write method is this one:

    public void Write()
    {
        //caracteres de terminacion
        buffer.AddRange(new byte[] { 0xBF, 0xB1 });
        try
        {
            if (!sp.IsOpen) sp.Open();
            sp.Write(buffer.ToArray(), 0, buffer.Count);
        }
        finally
        {
            sp.Close();
        }
    }

Update 2

I finally got it to work (ugly fix, but meh.)

Before each write to the serial port, I send a "blank" message with no delay. That clears the screen, before sending the actual message. hooray! and it works for whatever amount of seconds I sleep the thread

Answer 1

First of all, can you please clarify the thread's sleep time? System.Threading.Thread.Sleep() takes a milliseconds argument, not a 'seconds' argument.

Next, do you know that the serial port write() succeeds? (A hard coded delay of 10-20 msecs is not necessarily always long enough.)

To prevent overrunning, I do something like:

    public bool Send(byte[] bytes)
    {
        try
        {
            serialPort.Write(bytes, 0, bytes.Length);
            return true;
        }
        catch (Exception ex)
        {
            // log or note the error: can be TimeoutException or InvalidOperationException, etc
            return false;
        }
    }

Answer 2

There are several things that might affect your situation, not the least of which is the already-mentioned "you're talking seconds, but Sleep() takes a milliseconds argument, not seconds" issue.

You also need to look at length of time between characters sent. Flow control too. Serial port parameters (baud rate, etc...). And you need to know what the tolerance of your device is. Lost data on a serial transmission usually means you are overloading the device on the other end.

Answer 3

Do you know the device's algorithm for detecting end-of-message (EOM)? It could be that the device uses an intra-character timeout. That could explain why it works with N > 20, if no new characters showed up in the buffer in that time then the device might decide that the message was terminated and display the buffer. If you are putting ASCII code 10 at the end of the messages, it may be deciding that the rest of the message scrolls off the end of the one-line display and not show it.

That wouldn't explain the N < 9 working, though. Perhaps if data arrives without any delay at all the device interprets it as a script to display serially? The indication that that is the case is if the speed at which messages display doesn't vary for N = 0 to 9, but it does vary for all N's > 20. If N is in milliseconds you may not be able to confirm this.