On Thu, 2013-01-17 at 08:50 -0500, Greg Freemyer wrote:
Roger Oberholtzer <roger@opq.se> wrote:
I feel funny even asking the following, but I have a situation that I need to resolve.
1. When opening a serial port on Linux, the very first read() will only return data that arrived from the point of the open. That is, any data in kernel buffers will not be seen. Right?
Just to be sure, we do a flush after the open:
tcflush(serialPort, TCIOFLUSH);
So, is there any chance we see data from before the open/flush() call?
2. Similar question about opening a TCP/IP socket. Could we expect to see any data that arrived before the connect() call? Is there any need to flush the socket?
The reason I ask is that I have two devices that provide time tagged data. One is a Trimble GPS receiver on a serial port. The other is a data collection device (time-synced with its own GPS receiver) on a TCP/IP socket. It is expected that the two, when opened, should be reporting rather similar times. Unfortunately, the two differ by up to 20 seconds. It seems that the trend is that the network device starts out 20 seconds in the future relative to the serial port device.
My suspicion is that the data collection device is not syncing properly with it's own GPS receiver. Before I complain to the manufacturer, I want to be certain I have not missed something.
Roger,
For rs-232 there is no kernel level concept of a connection. I don't know what the receiver does if data comes in without a open file handle, but the sending side can only send it or queue it up.
If you are using rts/cts hardware flow control the data could easily be sitting in the sending device until you open the tty and raise cts.
Hard to guess what the GPS sender does in this respect. What I can say is that there are no gaps at the start of the data stream. If the sender's FIFO fills up and I get that data initially, I would expect it to have some older time stamp from when the data went in the FIFO. Then, while the FIFO was full (presumably waiting for my connection), data would have to be discarded, causing a gap.
You need to some how flush the output queue of the sender in that case.
No such control is allowed. The GPS simply sends NMEA data strings on port. You do not turn it on or off.
If you have a rs-232 monitor you should use it to see exactly what is going on. (I did tons of rs-232 work in the '90s, but nothing in the last 10 years.)
We are going to see if the GPS continues to send data when there is no reader. Perhaps the flow control lines are not used. I suspect that this is the case.
For sockets, there are not any kernel level queues on either side until the connection is established.
As I suspected. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org