RS232 slow reads

[Ibanez]

Hi,

I am trying to read information out of a RS232 sensor [M.F. Meter]. Everything is working fine, but I think my reading are slower than what the manufacturer claims I should be getting.

They told me that the standard data frame is 43 characters in length and at 19.2kBauds it should take just over 22mSec to transmit and at 38.4 kBauds it should be just over 11mSec.

The numbers I am getting are around 50ms.

I tried using VISA and .NET instructions to do the readings, but in both cases I got the same results.

My basic Setup:

 I init/configure the serial port, flash the buffer, and then in a loop I read from the buffer. [I tried flushing the buffer after the read, but no difference]

The way I'm timing how long it takes to read one line from the buffer. It's by using two tick counters and reading the difference.

I am trying to determine what "real time" will mean in my app and so far everything else it's under 15 ms. Reading serial seems to be "bottle neck". It's not a huge deal, but if I can improve on it it would be best.  

[similar setup]

I'll appreciate any help you can provide me to help improve on it or point in the right direction.

---

LV2011DevSuite, Win7,

---

[RavensFan · Accepted solution]

Are you sure the device is sending data consecutively, or is there a gap between packets of data?

It may only take 22 msecs or 11 msecs to transmit the actual data, but there may be a pause between the actual packets as the device is doing its thing and preparing the next packet of data for transmission.

[Ibanez]

Hi Ravens Fan,

Thanks for the input. Actually I'm not a 100% sure the data if there any gap. I'll email the the manufacturer to confirm.

Using a terminal program I get this input [time stamp added by terminal program]

10:25:04.358>   +014.44 +079.70 +0000.0 +0000.0 N2

10:25:04.422>   +014.45 +079.70 +0000.0 +0000.0 N2

[64ms, slower than lv. not that help full, but hinting that you might be in the right track. I'll get back to you soon]

[Ibanez]

Hi Ravens Fan,

The manufacturer said that the sensor in automatic mode transmits data as fast ast the baud rate allows it. I take that as continuos transmit with no gaps

[RavensFan]

Honestly, just because they said that, I don't know if I would believe them, or necessarily interpret it that there are no time gaps in the data.

I think the best way you could confirm that would be to monitor the serial line using an oscilloscope.  Once you get the scope settings just right, I think you'll be able to see the bits.  Capture enough data so that you can see what should be multiple packets of data.  See if you can and periods of time where you don't see bits.  Try it at different baud rates as well.  It might be easier to get see this at a slower baud rate to start, then work your way up to faster baud rates.

[Ibanez]

Thanks,

That seems like a sane approach. I was a little puzzle with the company comments.

I quote "Unless you have a very fast processor, it is unlikely that your LabView program will be able to keep up with streaming data." that just seems a little fishy to me. It's just serial data at "low speeds" not live streaming HD media...

While monitoring the input buffer bytes, LV seems to be consumming it as fast as the data shows in.

[RavensFan]

Do you have a sense of when this device was originally developed?  Was it in the last couple years or circa 1984?  A comment like that sounds like it was written in the early days of PC's where the PC would have had a problem keeping up with even moderate baud rates and hardware handshaking was a necessity to keep from overrunning tiny serial port buffers.

[Ibanez]

🙂

I know, right? Well it's a pretty  new device developed in the last couple of years.

I might try the oscilloscope test or just RS232 to another PC just to push it and see what kind of transfer speeds I get.

Thank you for your help...

[Ibanez]

Just in case:

I created a loop with two serial ports. I have one writing and another reading. I used the same length string message as the meter and I was able to get speeds that make sense.

@ 9600bps, 43bytes at ~40ms

@19200bps, 43bytes at ~20ms

@38400bps, 43Bytes at ~11ms

Then I tested the meter at these speeds (also at 2400bps) and the only time the reading speed change was at 2400 when it slow down.

Then if I receive data at 50ms it must be that the meter makes the message available around 40ms.

Thanks again for your help...

[NOTE to self: don't always trust the manufacturers]

[RavensFan]

I'm glad to hear you were able to test some things out to figure out what is actually going on.