RS485 guard-time

Started by pozz July 15, 2016
I just noticed a nice feature of SAM C2x microcontrollers from Atmel. It 
is the RS485 support, i.e. one pin (TE) goes high when the UART is 
transmitting and goes immediately low when the last byte was really 
shifted out, including stop bits.

There is an additional feature that Atmel named "guard time".

"
For RS485 mode, the guard time is programmable from 0-7 bit times and 
defines the time that the transmit enable pin (TE) remains high after 
the last stop bit is transmitted and there is no remaining data
to be transmitted.
"

When the guard time could be useful? I think it's better to disable the 
transmitter as soon as possible to avoid corrupting the next message 
from another node on the bus.

Maybe it is desirable another *different* feature, a guard time *before* 
starting the transmission of a packet.  This would give some time to the 
node that has just finished the transmission that needs to disable its 
transmitter (...and doesn't have the hardware control of TE pin).


On Fri, 15 Jul 2016 13:04:47 +0200, pozz <pozzugno@gmail.com> wrote:

>I just noticed a nice feature of SAM C2x microcontrollers from Atmel. It >is the RS485 support, i.e. one pin (TE) goes high when the UART is >transmitting and goes immediately low when the last byte was really >shifted out, including stop bits.
Really good feature compared to dumb 14550 UARTs. Those stupid UARTs generate an interrupt, when the last byte is _moved_ into the shift register, not when the last stop bit is shifted out causing a huge amount of problems.
>There is an additional feature that Atmel named "guard time". > >" >For RS485 mode, the guard time is programmable from 0-7 bit times and >defines the time that the transmit enable pin (TE) remains high after >the last stop bit is transmitted and there is no remaining data >to be transmitted.
Modbus RTU requires 1.5 and 3.5 character idle times between messages i.e. 15 to 35 bit times so the 0-7 bit "guard time" is too little :-(. Fortunately only 0 bit guard time is sufficient assuming "fail safe" (as written in the RS-485 standard with quotes-) termination, i.e. 100-120 ohm termination with proper line pull up/down resistors.
>When the guard time could be useful? I think it's better to disable the >transmitter as soon as possible to avoid corrupting the next message >from another node on the bus.
Would be useful for Modbus RTU, but the guard time is too short.
>Maybe it is desirable another *different* feature, a guard time *before* >starting the transmission of a packet. This would give some time to the >node that has just finished the transmission that needs to disable its >transmitter (...and doesn't have the hardware control of TE pin).
Modbus RTU also requires putting the transmitter into the actively driven idle "1" state, 1.5 character times (15 bit times) before starting to send the actual message. Apparently Atmel designers have heard some protocol specifications, but unfortunately have not understood the requirements of the most common industrial protocol (Modbus RTU) but have not understood the real timing requirement of 1.5 and 3.5 character times. Fortunately, in practice, you can be a bit sloppy with these requirements in some spacial cases, especially with "fail safe" termination".
> Modbus RTU requires 1.5 and 3.5 character idle times between messages > i.e. 15 to 35 bit times so the 0-7 bit "guard time" is too little :-(. >
1.5 is "inter-character" time inside a message. This is the max. idle time between characters (not messages) inside a valid message. 3.5 is the "inter-message" idle time.
> Modbus RTU also requires putting the transmitter into the actively > driven idle "1" state, 1.5 character times (15 bit times) before > starting to send the actual message. >
I didn't heard of that until now. Please give a reference.
On Fri, 15 Jul 2016 21:30:46 -0700 (PDT), raimond.dragomir@gmail.com
wrote:

>> Modbus RTU requires 1.5 and 3.5 character idle times between messages >> i.e. 15 to 35 bit times so the 0-7 bit "guard time" is too little :-(. >> >1.5 is "inter-character" time inside a message. This is the max. idle time between >characters (not messages) inside a valid message.
Yes
>3.5 is the "inter-message" idle time.
Yes I was just trying to point that the 0-7 bit time is too little.
>> Modbus RTU also requires putting the transmitter into the actively >> driven idle "1" state, 1.5 character times (15 bit times) before >> starting to send the actual message. >> >I didn't heard of that until now. Please give a reference.
The inter-character time and the preamble times are closely related. In the time when the original RS-485 standard was written, "fail safe" termination was apparently just an option. Many systems did not have any terminations or pull up/down resistors. In such a system, when a station turned the transmitter off, the line was in a very high impedance state, floating anywhere and sensitive to noise coupled asymmetrically to the both lines. This could cause some false start bit generations, i.e. a sufficiently long (a half bit time at least "0" state, which is interpreted as a start bit. The UART would then often capture 0xFF, 0xFE or even 0xF0 depending of the width of the spurious "0" pulse (remember LSBs is sent first immediately after the start bit). The 1.5 inter-character limit helps separate spurious noise from the actual start of the message. Turning the transmitter on 1.5 character times before the actual frame puts the line into a low impedance idle "1" state, eliminating most of the spurious start bits 1.5 character times before the actual frame reception. Having a false start bit less than 1.5 character times before the actual frame, will put a spurious prefix character in front of the received Modbus message and if less than 1 character times before the actual frame will even destroy the bit synch of the whole frame. Thus, it is a good idea to stabilize the line with a low impedance idle state just before the actual message frame.
> >> Modbus RTU also requires putting the transmitter into the actively > >> driven idle "1" state, 1.5 character times (15 bit times) before > >> starting to send the actual message. > >> > >I didn't heard of that until now. Please give a reference. > > The inter-character time and the preamble times are closely related. > In the time when the original RS-485 standard was written, "fail safe" > termination was apparently just an option. Many systems did not have > any terminations or pull up/down resistors. > > In such a system, when a station turned the transmitter off, the line > was in a very high impedance state, floating anywhere and sensitive to > noise coupled asymmetrically to the both lines. This could cause some > false start bit generations, i.e. a sufficiently long (a half bit time > at least "0" state, which is interpreted as a start bit. The UART > would then often capture 0xFF, 0xFE or even 0xF0 depending of the > width of the spurious "0" pulse (remember LSBs is sent first > immediately after the start bit). > > The 1.5 inter-character limit helps separate spurious noise from the > actual start of the message. Turning the transmitter on 1.5 character > times before the actual frame puts the line into a low impedance idle > "1" state, eliminating most of the spurious start bits 1.5 character > times before the actual frame reception. > > Having a false start bit less than 1.5 character times before the > actual frame, will put a spurious prefix character in front of the > received Modbus message and if less than 1 character times before the > actual frame will even destroy the bit synch of the whole frame. > > Thus, it is a good idea to stabilize the line with a low impedance > idle state just before the actual message frame.
While this is a very nice theory (I never worked with completely "open" rs485 nets, they have at least puyl-ups and pull-downs, so I didn't encounter such problems, nor I needed that 1.5 character time idle rs485 driving) you said: "Modbus RTU also requires..." This sounds like the modbus standard specifies this. That's why I asked for a reference. If this is not actually "required" by the standard, please specify so.
Il giorno venerd&igrave; 15 luglio 2016 22:02:12 UTC+2, upsid...@downunder.com ha
scritto:

> Apparently Atmel designers have heard some protocol specifications, > but unfortunately have not understood the requirements of the most > common industrial protocol (Modbus RTU) but have not understood the > real timing requirement of 1.5 and 3.5 character times.
well, I'using a AVR32 that has a "timer" embedded in the usart module that trigger an interrupt some time (that you can set) after a byte is received, and is long enough for the 3.5 char time, very useful for modbus rtu. as for the guard-time: boh. Bye Jack
On Tue, 19 Jul 2016 02:18:23 -0700 (PDT), Jack <jack4747@gmail.com>
wrote:

>Il giorno venerd&#2013265932; 15 luglio 2016 22:02:12 UTC+2, upsid...@downunder.com
ha scritto:
> >> Apparently Atmel designers have heard some protocol specifications, >> but unfortunately have not understood the requirements of the most >> common industrial protocol (Modbus RTU) but have not understood the >> real timing requirement of 1.5 and 3.5 character times. > >well, I'using a AVR32 that has a "timer" embedded in the usart module that trigger
an interrupt some time (that you can set) after a byte is received, and is long enough for the 3.5 char time, very useful for modbus rtu.
> >as for the guard-time: boh. > >Bye Jack
I have been using the QUICC coprosessors on MC68360 an later PPC models. The character time based timing of QUICC is quite sufficient for Modbus (done myself), but still violates the Modbus standard bit oriented standards quite violently.