SerialPort

[Magne]

Using SerialPort
ReceivedBytesThreshold = 1

Handling DataReceived event as:
int noOfBytesInBuffer = myPort.BytesToRead;
byte[] myBuffer = new byte[noOfBytesInBuffer];
myPort.Read(myBuffer, 0, noOfBytesInBuffer)

noOfBytesInBuffer is always set to 8 in my case (the transmissions on the
line are chunks of 8 bytes).

Why this behaviour ?
It seems like the OS (XP SP2) waits (approx. 16 ms) to see if more bytes are
coming (FIFO buffer is disabled).
I had a similar problem a couple of years ago, but by using W2k I did not
have the problem, now I do not have any W2k available anymore.

Some registry setting ?

[Dick Grier]

Hi,

>>

It seems like the OS (XP SP2) waits (approx. 16 ms) to see if more bytes are
coming (FIFO buffer is disabled).
<<

Do NOT disable the FIFO receive buffer. This will reduce your performance.
You should leave it a 14 (High), IMO. There are very few good reasons to
set the FIFO size to a lower value.

There is no way to know how many bytes will be delivered in a "chunk." 16
mS seems unreasonable to me, though. What is the serial speed? What else
is going on at the same time? Ususally, 1-2 mS will be what you expect.
However, system latency is totally unpredicatable.

How are you measuring 16 mS? Perhaps you are not seeing what you think you
are seeing.

No, there is no Registry setting to contol any part of the Windows serial
processing behavior.

BTW, you are creating a new buffer each time you want to read data. Your
code will be slightly faster if you change the scope of myBuffer so that it
isn't created each time, but is reused.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Magne]

Thanks for reply

My code is not my real code, only to show principles (I do not create array
every time).
Speed is 9600
I can see because I report the time of each "arrival" (or at least what
seems to be the arrival, perhaps some .net latency or something), and these
"always" comes with 16 ms intervals.

By the way, now (SP 2 ?) diabling of FIFO has indeed effect (I didn'r
realize that machine restart was neccessary).
With e.g. FIFO set to 14, is it then possible to detect "silent line" of
approx 4-5 ms ?

"Nothing" else is going on at the same time (but of course some background
services)

"Dick Grier" <dick_grierNOSPAM@.msn.comwrote in message
news:em****************@TK2MSFTNGP05.phx.gbl...

Hi,

>>>

It seems like the OS (XP SP2) waits (approx. 16 ms) to see if more bytes
are
coming (FIFO buffer is disabled).
<<

Do NOT disable the FIFO receive buffer. This will reduce your
performance. You should leave it a 14 (High), IMO. There are very few
good reasons to set the FIFO size to a lower value.

There is no way to know how many bytes will be delivered in a "chunk." 16
mS seems unreasonable to me, though. What is the serial speed? What else
is going on at the same time? Ususally, 1-2 mS will be what you expect.
However, system latency is totally unpredicatable.

How are you measuring 16 mS? Perhaps you are not seeing what you think
you are seeing.

No, there is no Registry setting to contol any part of the Windows serial
processing behavior.

BTW, you are creating a new buffer each time you want to read data. Your
code will be slightly faster if you change the scope of myBuffer so that
it isn't created each time, but is reused.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Dick Grier]

Hi,

Sorry, I have been out of the country, so my reply has been delayed.

>>

With e.g. FIFO set to 14, is it then possible to detect "silent line" of
approx 4-5 ms ?
<<

Perhaps... Perhaps not. There are no real-time assurances in Windows. If
you have a really fast processor and nothing much else is going on then,
perhaps becomes "probably, most of the time."

>>

"Nothing" else is going on at the same time (but of course some background
services)
<<

There are lots of things going on "behind the scenes" so killing any
services that aren't needed will improve real-time performance. And, it is
possible to fiddle the process Priorities for your application, too. Your
actual experience will vary from Good to OK (maybe) to "you simply cannot do
it," depending on too many variable to say. So, you will have to deploy a
test to see.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.