 |
 |
| View previous topic :: View next topic |
| Author |
Message |
arunb
Joined: 08 Sep 2003
Posts: 492
Location: India
|
| Is flow control really required for professional systems |
 Posted: Sun Nov 28, 2004 8:57 am |
 |
|
Hi,
Is flow control really required for a professional datalogger ??
I usually use no flow control , handshaking is done by a single character sent regularly by the PC and then by the PIC in turn.
Kindly advise whether I should implement handshaking, also let me know how I can verify whether the received data is correct and has not been corrupted during transmission.
thanks
arunb |
|
 |
Ttelmah
Guest
|
| Re: Is flow control really required for professional systems |
| Posted: Sun Nov 28, 2004 10:32 am |
|
|
| arunb wrote: | Hi,
Is flow control really required for a professional datalogger ??
I usually use no flow control , handshaking is done by a single character sent regularly by the PC and then by the PIC in turn.
Kindly advise whether I should implement handshaking, also let me know how I can verify whether the received data is correct and has not been corrupted during transmission.
thanks
arunb |
Most 'professional' data logger applications do not use 'flow control' (because the commonest links are using signalling standards like RS485, without extra wires for this). Instead the systems are designed to handle a complete 'packet' (whatever the size may be), without needing to pause. Most systems will implement a CRC. The method chosen will depend on the nature of the link. For example, a typical system, would have an ID, and marker number at the start of the packet, and a CRC at the end. Then the 'slave' responds, if a correct CRC is received, acknowledging the packet, with both the ID, and marker number. The master will after an interval re-transmit if an acknowledgement is not received. Conversely, on a link which is unidirectional, it'd be common to send a hamming coded version of the data, allowing recovery, even if several bits are lost. This then largely obviates the need to reply, but even here, some form of 'error alert' system should exist to deal with the case where complete packets are lost, or the link is broken.
You need to work out the likely error rate of your link, the nature of the likely errors (single bit, or sections of data), the available bandwidth, the required data rate, and what error rate you can 'accept'.
Best Wishes |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Nov 28, 2004 7:04 pm |
|
|
| Quote: | | Most 'professional' data logger applications do not use 'flow control' |
I do not agree with this comment. Data loggers that has been designed to be remotely interogated will usually support flow control either in hardware via CTS / RTS or in software with XON/XOFF.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sun Nov 28, 2004 7:18 pm |
|
|
| Quote: | | I do not agree with this comment. Data loggers that has been designed to be remotely interogated will usually support flow control either in hardware via CTS / RTS or in software with XON/XOFF. |
If data is sent in packets and the packets have acknowledgements then there is really not a need for flow control. The acking and naking of packets can handle this. Futhermore, the embedded device is usally sending the data to the PC which usually can handle the large amount of data. Now if you still want to disagree, I guess dataloggers will disappear along with the serial port on PC's. The last time I checked, USB doesn't have any hardware flow control  |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Nov 28, 2004 7:35 pm |
|
|
| Quote: | | If data is sent in packets and the packets have acknowledgements then there is really not a need for flow control. |
This works if the entire transmission path is guarenteed to handle the maximum MTU of a packet. If not, you need flow control. Also packet by packet transmission in this "lock-step" format is very inefficent for the remote interrogation of a data logger as each packet requires two round trip delays. Send packet - wait till it gets to the destination (speed of light propagation) process packet - return ack - wait till it gets to the source (SOLP) send next packet. A lock-step protocol is both inefficient in tthe effective utilization of the transmission link as well as having a significantly higher operational expense if the tranmsission link uses a timed-based billing system.
This is why window based protocols are used either fixed or sliding transmission windows - once you do this then flow control is required.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sun Nov 28, 2004 8:00 pm |
|
|
| Quote: | | This works if the entire transmission path is guarenteed to handle the maximum MTU of a packet. |
Yeah, that's why you set the packet size accordingly. If needed, segmentation is an option.
| Quote: | | Also packet by packet transmission in this "lock-step" format is very inefficent for the remote interrogation of a data logger as each packet requires two round trip delays. |
An ACK can be a single byte. Not much of a delay!
| Quote: | | wait till it gets to the destination (speed of light propagation) process packet |
Doesn't have to process the packet but rather ensure the data passes some sort of validation through something such as a CRC.
Flow control doesn't give you a means of signaling the sender of invalid data. The ACK NAK will. Humm, for a "Professional" data logger I think I would rather have some error detecting over useless flow control any day. Where is that hardware flow control on RS485, Arcnet, ethernet, USB not to mention wireless technologies? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Nov 28, 2004 8:31 pm |
|
|
| Quote: | | Yeah, that's why you set the packet size accordingly. If needed, segmentation is an option. |
There is another name for segmentation. It is called local flow control.
| Quote: | | An ACK can be a single byte. Not much of a delay! |
Not much delay? How about a little tranmission theory. Let's say you have a data logger located 5000km away (i have several). Effective speed of transmission through copper or atsmoshere is 0.7 x 300000000 meters per second. Round trip delay is 50ms. Therefore the maximum packet transfer rate (ignoring other delays) is 20 packets per second. If my "packet size" is 64 bytes then the maximum possible throughput is 1280 bytes per second. Pretty poor don't you think? Especially for a "professional" data logger.
Flow control has nothing to do with CRC - they perform two completely different functions.
| Quote: | | RS485, Arcnet, ethernet, USB not to mention wireless technologies? |
RS485 - let's see - it can use XON/OFF.
Arcnet - who cares?
Ethernet - it has back-off at the physical layer. Protocols than run above it have their own. TCP uses windowing. UDP it is up to the application programmer. Note that both flow control and error detection (via CRC at the link layer, and checksum at the network layer) are used together.
USB - This uses flow control. I have products that implement this today including ones embedded in "professional" data loggers.
Wireless - anything that implements an ethernet stack inherits the same flow control mentioned for ethernet.
In the case of wireless modems - virtually every wireless modem you purchase off-the-shelf has flow control built in - and so they should.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sun Nov 28, 2004 8:43 pm |
|
|
Andrew, you need to read more carefully,
| Quote: | | Where is that hardware flow control |
Hardware son, I said nothing of software flow control. And yes, sending packets with acknowledgements is much like software flow control with the addition of detecting missed or invalid data. How does XON/XOFF work for binary data? I don't think I have ever seen an XON or XOFF in an ethernet packet either 
| Quote: | Arcnet - who cares?
|
We do, building automation systems still use this today. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Nov 28, 2004 9:23 pm |
|
|
| Quote: | | Hardware son, I said nothing of software flow control. And yes, sending packets with acknowledgements is much like software flow control with the addition of detecting missed or invalid data. How does XON/XOFF work for binary data? |
Your right - I missed the hardware point but this only affects my answer to RS485 all the other comments stand. RS485 is an asynchronoous protocol that can be used half duplex, full duplex or simplex based. The implementation most commonly see in industrial deployments is simplex where you have a single master arbitrating access to a shared bus. In a simplex protocol flow control is inherently present.
| Quote: | | I don't think I have ever seen an XON or XOFF in an ethernet packet either |
Ethernet implements hardware flow control via two methods, backpressure (jamming) at the physical layer or pause frames. You will see backpressure used on cheap switches (those with limited buffering capabilities). "Pause frames" you will see on GE interfaces as it is a manatory part of the spec. These "pause frames" are "wait a bit" messages as opposed to specific XON and XOFF but the end result is the same.
| Quote: | Arcnet - who cares?
We do, building automation systems still use this today. |
Fair enough. ARCNET has flow control built into the datalink layer - you get flow control automatically.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Nov 29, 2004 9:38 am |
|
|
Okay, so it looks like you agree that it is not necessary to have a hardware line for flow control since most do not have physical connects for them. That leads to a software flow control, Xon/Xoff. Now unless you are transmitting ascii data this isn't going to work either. So there is some command be it a pause frame or whatever that acts as a signal to stop (or delay) and a signal to resume transmission. This seems to me to indicate that
| Quote: | | This works if the entire transmission path is guarenteed to handle the maximum MTU of a packet |
So our system must handle the MTU of a packet. Now, lets say we are looking for acks and/or naks of packets. Doesn't this mean
| Quote: | | you get flow control automatically |
| Quote: | Not much delay? How about a little tranmission theory. Let's say you have a data logger located 5000km away (i have several). Effective speed of transmission through copper or atsmoshere is 0.7 x 300000000 meters per second. Round trip delay is 50ms. Therefore the maximum packet transfer rate (ignoring other delays) is 20 packets per second. If my "packet size" is 64 bytes then the maximum possible throughput is 1280 bytes per second. Pretty poor don't you think? Especially for a "professional" data logger.
|
Yeah, I say that stinks. Maybe you should increase the packet size. Then you would get much more through put. But if you are stuck with it and think those delays are unacceptable, then I would treat the link as thou it were a unidirectional link in which case:
| Quote: | Conversely, on a link which is unidirectional, it'd be common to send a hamming coded version of the data, allowing recovery, even if several bits are lost. This then largely obviates the need to reply, but even here, some form of 'error alert' system should exist to deal with the case where complete packets are lost, or the link is broken.
|
and probably send a pause frame |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Nov 29, 2004 10:18 am |
|
|
This is why the acknowledge should include the 'packet number' in some form. The key then is that the transmission system does not have to wait for each packet to be individually acknowledged, but can instead (assuming the link is full duplex), keep sending packets, and then 'tick them off' in an an internal list when the acknowledgements are seen. In a similar way, I use a radio link that is half duplex, and has a turnround time similar to your 'long wire' example. I send a group of packets, and then at the start of the next second, check which ones have been acknowledged. The next second, I send the 'missing' ones, and the next set.
Best Wishes |
|
|
arunb
Joined: 08 Sep 2003
Posts: 492
Location: India
|
| RE: |
| Posted: Mon Nov 29, 2004 11:13 am |
|
|
Hi,
Thank you all for the replies.
Apart from these issues , should one expect to loose data ( due to noise or otherwise) while communicating through the RS 232 port.
Since the distances are not very long, I would expect most of the data to come through.
thanks
arun |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Nov 29, 2004 11:19 am |
|
|
Always expect the unexpected 
It can happen, but if the distance is short and the environment is not that noisy the data shouldn't have a problem getting through. There is the chance that the receiving device is busy doing something and may miss some data. So you should plan on the possibility of data getting lost even though it may not ever happen (just because it could). Its kind of like car insurance. Never have needed it but it sure nice to know its there just in case |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
