SerialPort Caching?

B

Brandon

Platform is WM2K3 (not SE) with compact framework 2.0.

I have a thread that is using SerialPort.Readline() to read raw GPS data
from an RS232 GPS device (the RS232 port that the GPS device is plugged into
is on the vehicle cradle that the device is in). If I just open the serial
port and then repeatedly call SerialPort.Readline(), I seem to continue to
get data off of the serial port for a period of time after I have un-cradled
the device (effectively disconnecting it from the RS232 port). The length of
the period of time seems to be directly related to the lenght of time that
this thread is successfully reading from the port (for example, I put the
device in the cradle and read for 5 seconds, then uncradle, I continue to get
data from the SerialPort for X seconds...If I put the device in the cradle
and read for 50 seconds, then uncradle, I continue to get data from the
SerialPort for 10x seconds...not sure what the exact numbers are, just trying
to give a clear example).

The basics of this method looks something like:
SerialPort.Open();
while(!shutdown)
{
data = SerialPort.Readline();
...
}
SerialPort.Close();

If I instead repeatedly open the SerialPort, read until I get a parseable
update that has an acceptable quality value, and then close the SerialPort, I
do not have this issue, but instead I just get updates very slowly (there is
a lot of trash in the data for the first few reads, then you get a bunch of
initilization sentances, then you start getting position updates), and they
seem to jump around a lot.

The basics of this method look something like:
while(!shutdown)
{
SerialPort.Open()
Until(gotAGoodRead)
{
data = SerialPort.Readline();
...
}
SerialPort.Close()
}

I'd like to be able to keep the port open so I can read faster, but the
caching behavior is a serious problem...any ideas?
 
G

Guest

First suggestion is to abandon ReadLine, as it only causes problems. Just
read the data directly and look for line breaks yourself. Doing that will
probably eliminate any kind of caching. If for some reason data is still
cached (and I can only imagine that if the incoming data is faster than you
can read, and with a GPS I just can't believe it) then when a disconnect
happens, flush the buffer. Again, I can't imagine that would ever happen
though.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
G

Guest

Yeah, Port.ReadLine is poorly implemented (ok, that's generous - it's a
totally broken piece of you-know-what) and is the worst thing they ever put
in. I can't say I've ever seen an instance where it was used and it
actually worked.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
 
G

Graham McKechnie

Hi Chris,

Your comments re ReadLine come as a bit of a shock. I've been using ReadLine
in a couple of applications, one is gps and another is obd and I've never
come across a problem using it in either of them. The obd app, also has a
desktop version and I've never experienced problems with either - same code
shared by desktop and pda.

Why do you claim it is totally broken piece of you-know-what?

Graham
 
G

Guest

Experience.

ReadLine looks at the buffer for a line break, however I've seen in many
cases that if the data that has come in doesn't end very nicely with a line
break (so let's say we have half an NMEA sentence trailing in the buffer)
then that data is often either dropped on the floor or ignored in the next
call to ReadLine one additional data comes in. IIRC Dick Grier (who does a
*lot* of serial work) had also seen bed behavior along these same lines. If
you have data that has errors in it, I've also seen the ReadLine call f it
all up and become confused about it's location, causing all sorts of grief
for developers. The performance tends to also blow in the cases that it
miraculously does work.
ReadLine has also been known to throw a NullReferenceException if you close
the port during a read.

Just a few threads that talk about some of the issues seen in the wild:

http://groups.google.com/group/micr...a/ccfa3ec9cea9213a?lnk=st&q=#ccfa3ec9cea9213a
http://groups.google.com/group/micr...d/636ec9590f1e25df?lnk=st&q=#636ec9590f1e25df
http://groups.google.com/group/micr...9/911486572cd5febb?lnk=st&q=#911486572cd5febb
http://groups.google.com/group/micr...t.framework.compactframework#a959970dd5d1220e


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
 
G

Graham McKechnie

Chris,
Experience.

Interesting, my experience has been the exact opposite. However you've got
me going and so I think I will do some more testing.

Dropping the odd GPS sentence is hardly going to stuff things up much if
there is another one following. I'm not suggesting deliberately dropping
something, but you do have to test whether its a valid sentence anyway and
reject it if it isn't, so losing a single sentence isn't going to do much
harm

I've read through those threads you posted and I can honestly say I never
struck anything like that - the most serious issues I've had is when the pda
automatically shutsdown and how to handle that gracefully. My gps stuff is
for golf and a round of golf does tend to tax the battery life of some pdas.
The following helped with that along time ago now
http://blogs.msdn.com/anthonywong/archive/2006/03/03/542625.aspx
I've also seen the ReadLine call f it all up and become confused about
it's location, causing all sorts of grief for developers. The performance
tends to also blow in the cases that it miraculously does work.

The obd stuff is coming from a vehicle engine and transmission ecus and
because I log every message, it would be very obvious if I was loosing data
or getting incorrect data because something got dropped on the floor.

It is a bit of a mystery why some are having problems with Readline and not
others, maybe I just got lucky!

Graham
 
G

Guest

Yep, I hit problem a couple times and just never looked back. I'm fine with
line parsing myself, so I don't much care if they ever fix it - I just like
to let others be aware of the pitfalls.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



Graham McKechnie said:
Chris,
Experience.

Interesting, my experience has been the exact opposite. However you've got
me going and so I think I will do some more testing.

Dropping the odd GPS sentence is hardly going to stuff things up much if
there is another one following. I'm not suggesting deliberately dropping
something, but you do have to test whether its a valid sentence anyway and
reject it if it isn't, so losing a single sentence isn't going to do much
harm

I've read through those threads you posted and I can honestly say I never
struck anything like that - the most serious issues I've had is when the
pda automatically shutsdown and how to handle that gracefully. My gps
stuff is for golf and a round of golf does tend to tax the battery life of
some pdas. The following helped with that along time ago now
http://blogs.msdn.com/anthonywong/archive/2006/03/03/542625.aspx
I've also seen the ReadLine call f it all up and become confused about
it's location, causing all sorts of grief for developers. The
performance tends to also blow in the cases that it miraculously does
work.

The obd stuff is coming from a vehicle engine and transmission ecus and
because I log every message, it would be very obvious if I was loosing
data or getting incorrect data because something got dropped on the floor.

It is a bit of a mystery why some are having problems with Readline and
not others, maybe I just got lucky!

Graham

Experience.

ReadLine looks at the buffer for a line break, however I've seen in many
cases that if the data that has come in doesn't end very nicely with a
line break (so let's say we have half an NMEA sentence trailing in the
buffer) then that data is often either dropped on the floor or ignored in
the next call to ReadLine one additional data comes in. IIRC Dick Grier
(who does a *lot* of serial work) had also seen bed behavior along these
same lines. If you have data that has errors in it, I've also seen the
ReadLine call f it all up and become confused about it's location,
causing all sorts of grief for developers. The performance tends to also
blow in the cases that it miraculously does work.
ReadLine has also been known to throw a NullReferenceException if you
close the port during a read.

Just a few threads that talk about some of the issues seen in the wild:

http://groups.google.com/group/micr...a/ccfa3ec9cea9213a?lnk=st&q=#ccfa3ec9cea9213a
http://groups.google.com/group/micr...d/636ec9590f1e25df?lnk=st&q=#636ec9590f1e25df
http://groups.google.com/group/micr...9/911486572cd5febb?lnk=st&q=#911486572cd5febb
http://groups.google.com/group/micr...t.framework.compactframework#a959970dd5d1220e


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com




Graham McKechnie said:
Hi Chris,

Your comments re ReadLine come as a bit of a shock. I've been using
ReadLine in a couple of applications, one is gps and another is obd and
I've never come across a problem using it in either of them. The obd
app, also has a desktop version and I've never experienced problems with
either - same code shared by desktop and pda.

Why do you claim it is totally broken piece of you-know-what?

Graham


"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
Yeah, Port.ReadLine is poorly implemented (ok, that's generous - it's a
totally broken piece of you-know-what) and is the worst thing they ever
put in. I can't say I've ever seen an instance where it was used and
it actually worked.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



You are a genius. Works great. Thanks for the tip!

:

First suggestion is to abandon ReadLine, as it only causes problems.
Just
read the data directly and look for line breaks yourself. Doing that
will
probably eliminate any kind of caching. If for some reason data is
still
cached (and I can only imagine that if the incoming data is faster
than you
can read, and with a GPS I just can't believe it) then when a
disconnect
happens, flush the buffer. Again, I can't imagine that would ever
happen
though.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



Platform is WM2K3 (not SE) with compact framework 2.0.

I have a thread that is using SerialPort.Readline() to read raw GPS
data
from an RS232 GPS device (the RS232 port that the GPS device is
plugged
into
is on the vehicle cradle that the device is in). If I just open
the
serial
port and then repeatedly call SerialPort.Readline(), I seem to
continue to
get data off of the serial port for a period of time after I have
un-cradled
the device (effectively disconnecting it from the RS232 port). The
length
of
the period of time seems to be directly related to the lenght of
time that
this thread is successfully reading from the port (for example, I
put the
device in the cradle and read for 5 seconds, then uncradle, I
continue to
get
data from the SerialPort for X seconds...If I put the device in the
cradle
and read for 50 seconds, then uncradle, I continue to get data from
the
SerialPort for 10x seconds...not sure what the exact numbers are,
just
trying
to give a clear example).

The basics of this method looks something like:
SerialPort.Open();
while(!shutdown)
{
data = SerialPort.Readline();
...
}
SerialPort.Close();

If I instead repeatedly open the SerialPort, read until I get a
parseable
update that has an acceptable quality value, and then close the
SerialPort, I
do not have this issue, but instead I just get updates very slowly
(there
is
a lot of trash in the data for the first few reads, then you get a
bunch
of
initilization sentances, then you start getting position updates),
and
they
seem to jump around a lot.

The basics of this method look something like:
while(!shutdown)
{
SerialPort.Open()
Until(gotAGoodRead)
{
data = SerialPort.Readline();
...
}
SerialPort.Close()
}

I'd like to be able to keep the port open so I can read faster, but
the
caching behavior is a serious problem...any ideas?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top