--- In l..., "Brendan Murphy"
wrote:
> I believe real hardware UARTs typically do 16x
sampling and
> filtering to remove such transient errors.
Oh really? Which one?
Jaya
LPC2103 I/O and processing speed to handle 6 serial ports.
Started by ●October 3, 2006
Reply by ●October 7, 20062006-10-07
Reply by ●October 7, 20062006-10-07
----- Original Message -----
From: "jayasooriah"
To:
Sent: Saturday, October 07, 2006 12:52 PM
Subject: [lpc2000] Re: LPC2103 I/O and processing speed to handle 6 serial
ports.
> --- In l..., "Brendan Murphy"
> wrote:
>> I believe real hardware UARTs typically do 16x sampling and
>> filtering to remove such transient errors.
>
> Oh really? Which one?
Here are a couple:
http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
http://www.exar.com/product.php?ProdNumber=XR16M752
Leon
--
Leon Heller, G1HSM
Suzuki SV1000S motorcycle
l...@bulldoghome.com
http://webspace.webring.com/people/jl/leon_heller/
From: "jayasooriah"
To:
Sent: Saturday, October 07, 2006 12:52 PM
Subject: [lpc2000] Re: LPC2103 I/O and processing speed to handle 6 serial
ports.
> --- In l..., "Brendan Murphy"
> wrote:
>> I believe real hardware UARTs typically do 16x sampling and
>> filtering to remove such transient errors.
>
> Oh really? Which one?
Here are a couple:
http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
http://www.exar.com/product.php?ProdNumber=XR16M752
Leon
--
Leon Heller, G1HSM
Suzuki SV1000S motorcycle
l...@bulldoghome.com
http://webspace.webring.com/people/jl/leon_heller/
Reply by ●October 7, 20062006-10-07
> >> I believe real hardware UARTs typically do 16x
sampling and
> >> filtering to remove such transient errors.
> >
> > Oh really? Which one?
>
> Here are a couple:
>
> http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
>
> http://www.exar.com/product.php?ProdNumber=XR16M752
>
LPC9XX
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022, INDIA.
Cell +919422113746
> >> filtering to remove such transient errors.
> >
> > Oh really? Which one?
>
> Here are a couple:
>
> http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
>
> http://www.exar.com/product.php?ProdNumber=XR16M752
>
LPC9XX
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022, INDIA.
Cell +919422113746
Reply by ●October 7, 20062006-10-07
--- In l..., "Leon Heller" wrote:
...
> > --- In l..., "Brendan Murphy"
> > wrote:
> >> I believe real hardware UARTs typically do 16x sampling and
> >> filtering to remove such transient errors.
> >
> > Oh really? Which one?
>
> Here are a couple:
>
> http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
>
> http://www.exar.com/product.php?ProdNumber=XR16M752
>
> Leon
I can see references to different sampling rates but there appears to
be no mention of filtering.
I was curious about the comment becuase I know of one experimental
design using majority gate filter. This one used odd oversampling.
With 16x (or any even number of oversampling) how is the indeterminate
state resolved?
Jaya
...
> > --- In l..., "Brendan Murphy"
> > wrote:
> >> I believe real hardware UARTs typically do 16x sampling and
> >> filtering to remove such transient errors.
> >
> > Oh really? Which one?
>
> Here are a couple:
>
> http://focus.ti.com/docs/prod/folders/print/tl16c2752.html
>
> http://www.exar.com/product.php?ProdNumber=XR16M752
>
> Leon
I can see references to different sampling rates but there appears to
be no mention of filtering.
I was curious about the comment becuase I know of one experimental
design using majority gate filter. This one used odd oversampling.
With 16x (or any even number of oversampling) how is the indeterminate
state resolved?
Jaya
Reply by ●October 7, 20062006-10-07
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
> > I believe real hardware UARTs typically do 16x sampling and
> > filtering to remove such transient errors.
>
> Oh really? Which one?
>
> Jaya
>
Jaya,
I think your filter to remove my posts to the forum for you is
broken!
To answer your question: there are plenty of UARTs that use 16x
sampling (see other posts for some specific ones). I was using the
term "filtering" in its generic sense (i.e. applying some operation
to an input signal - in this case a series of samples - to an output
signal - in this case a one or zero bit). I guess you'd have to
consult the designers of the UARTs to find out the exact techniques
they use.
Regards
Brendan
wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
> > I believe real hardware UARTs typically do 16x sampling and
> > filtering to remove such transient errors.
>
> Oh really? Which one?
>
> Jaya
>
Jaya,
I think your filter to remove my posts to the forum for you is
broken!
To answer your question: there are plenty of UARTs that use 16x
sampling (see other posts for some specific ones). I was using the
term "filtering" in its generic sense (i.e. applying some operation
to an input signal - in this case a series of samples - to an output
signal - in this case a one or zero bit). I guess you'd have to
consult the designers of the UARTs to find out the exact techniques
they use.
Regards
Brendan
Reply by ●October 7, 20062006-10-07
--- In l..., "Brendan Murphy"
wrote:
> Jaya,
>
> I think your filter to remove my posts to the forum for you is
> broken!
>
> To answer your question: there are plenty of UARTs that use 16x
> sampling (see other posts for some specific ones). I was using the
> term "filtering" in its generic sense (i.e. applying some operation
> to an input signal - in this case a series of samples - to an output
> signal - in this case a one or zero bit). I guess you'd have to
> consult the designers of the UARTs to find out the exact techniques
> they use.
>
> Regards
> Brendan
Actually I was surprised how well the filter worked and picked up
misinformation about filters!
Over sampling in UARTs determines sampling timer resolution and has
nothing to do with filtering noise or spikes as the original post
suggested, or any 'generic' sense as it like to believe.
Designers of UARTs know the difference between timing the frame and
filtering.
Jaya
wrote:
> Jaya,
>
> I think your filter to remove my posts to the forum for you is
> broken!
>
> To answer your question: there are plenty of UARTs that use 16x
> sampling (see other posts for some specific ones). I was using the
> term "filtering" in its generic sense (i.e. applying some operation
> to an input signal - in this case a series of samples - to an output
> signal - in this case a one or zero bit). I guess you'd have to
> consult the designers of the UARTs to find out the exact techniques
> they use.
>
> Regards
> Brendan
Actually I was surprised how well the filter worked and picked up
misinformation about filters!
Over sampling in UARTs determines sampling timer resolution and has
nothing to do with filtering noise or spikes as the original post
suggested, or any 'generic' sense as it like to believe.
Designers of UARTs know the difference between timing the frame and
filtering.
Jaya
Reply by ●October 8, 20062006-10-08
--- In l..., "jayasooriah" wrote:
>>
> Over sampling in UARTs determines sampling timer resolution and has
> nothing to do with filtering noise or spikes as the original post
> suggested, or any 'generic' sense as it like to believe.
>
> Designers of UARTs know the difference between timing the frame and
> filtering.
>
> Jaya
>
In addition to timing resolution, the oversampling is handy
to use for "debouncing" of the data, as I like to think of it.
Not "filtering", as in low pass of course, but mainly False Start-Bit
Detection. That's the most important point I think but this can
also be applied to the other bits where an average is taken over
the samples during the middle of the bit times and a vote is taken.
Here's some False Start-Bit Detection notes:
For instance, from Maxim:
http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/
"The Start bit is typically sampled at the mid bit time to check that
the level is still low, to ensure that the detected falling edge was
a Start bit not a noise spike. Another common improvement is to
sample each bit not simply once at the mid bit position (clock count
8 out of 16), but three times (clock counts 7, 8, and 9 out of 16)."
>From Philips SCC2691_2.pdf UART note:
"The receiver has a digital filter designed to reject "noisy" data
transitions and the receiver state machine was designed to reject
noisy start bits or noise that might be considered a start bit."
>From TI TL16PIR552:
"The UART tries to resynchronize after a framing error. To accomplish
this, it is assumed that the framing error is due to the next start
bit. The UART samples this start bit twice and then accepts the input
data..... The next character transfer is enabled after SIN goes to
the marking state for at least two RCLK samples and then receives the
next valid start bit."
Intersil 82C50A:
"Verifying the start bit prevents the receiver from assembling an
incorrect data character due to a low going noise spike on the SIN
input."
These 2 are from other forums but is relative to noise in the non
start bits bits too. We did this at my last job with those 10
software UARTS:
1)
"Many UART chips use the 16x clock to sample the RxD pin multiple
times for every bit, then they use a majority algorithm to determine
the final state of the bit (in case all samples don't agree)."
2)
"Before a start bit is recognized, you look for a couple of
consecutive mark samples (typically 3 or 4) before deciding
that it really is a start bit. THis kills noise effects. Then
sample at the bit mid points (the start bit mid point would be 4 or 5
clocks from the detection of the start in a 16x system). Sample
again every 16th clock to read the midpoints of the bits. If you
want to get fancier, you can sense several of the samples around the
mid points and vote on the level for a little more noise immunity."
etc....
boB
>>
> Over sampling in UARTs determines sampling timer resolution and has
> nothing to do with filtering noise or spikes as the original post
> suggested, or any 'generic' sense as it like to believe.
>
> Designers of UARTs know the difference between timing the frame and
> filtering.
>
> Jaya
>
In addition to timing resolution, the oversampling is handy
to use for "debouncing" of the data, as I like to think of it.
Not "filtering", as in low pass of course, but mainly False Start-Bit
Detection. That's the most important point I think but this can
also be applied to the other bits where an average is taken over
the samples during the middle of the bit times and a vote is taken.
Here's some False Start-Bit Detection notes:
For instance, from Maxim:
http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/
"The Start bit is typically sampled at the mid bit time to check that
the level is still low, to ensure that the detected falling edge was
a Start bit not a noise spike. Another common improvement is to
sample each bit not simply once at the mid bit position (clock count
8 out of 16), but three times (clock counts 7, 8, and 9 out of 16)."
>From Philips SCC2691_2.pdf UART note:
"The receiver has a digital filter designed to reject "noisy" data
transitions and the receiver state machine was designed to reject
noisy start bits or noise that might be considered a start bit."
>From TI TL16PIR552:
"The UART tries to resynchronize after a framing error. To accomplish
this, it is assumed that the framing error is due to the next start
bit. The UART samples this start bit twice and then accepts the input
data..... The next character transfer is enabled after SIN goes to
the marking state for at least two RCLK samples and then receives the
next valid start bit."
Intersil 82C50A:
"Verifying the start bit prevents the receiver from assembling an
incorrect data character due to a low going noise spike on the SIN
input."
These 2 are from other forums but is relative to noise in the non
start bits bits too. We did this at my last job with those 10
software UARTS:
1)
"Many UART chips use the 16x clock to sample the RxD pin multiple
times for every bit, then they use a majority algorithm to determine
the final state of the bit (in case all samples don't agree)."
2)
"Before a start bit is recognized, you look for a couple of
consecutive mark samples (typically 3 or 4) before deciding
that it really is a start bit. THis kills noise effects. Then
sample at the bit mid points (the start bit mid point would be 4 or 5
clocks from the detection of the start in a 16x system). Sample
again every 16th clock to read the midpoints of the bits. If you
want to get fancier, you can sense several of the samples around the
mid points and vote on the level for a little more noise immunity."
etc....
boB
Reply by ●October 8, 20062006-10-08
Thanks, Bob, that's exactly what I meant!
Brendan
--- In l..., "bobtransformer" wrote:
>
> --- In l..., "jayasooriah" wrote:
> >>
> > Over sampling in UARTs determines sampling timer resolution and
has
> > nothing to do with filtering noise or spikes as the original post
> > suggested, or any 'generic' sense as it like to believe.
> >
> > Designers of UARTs know the difference between timing the frame
and
> > filtering.
> >
> > Jaya
> > In addition to timing resolution, the oversampling is handy
> to use for "debouncing" of the data, as I like to think of it.
> Not "filtering", as in low pass of course, but mainly False Start-
Bit
> Detection. That's the most important point I think but this can
> also be applied to the other bits where an average is taken over
> the samples during the middle of the bit times and a vote is taken.
> Here's some False Start-Bit Detection notes:
>
> For instance, from Maxim:
>
> http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/
>
> "The Start bit is typically sampled at the mid bit time to check
that
> the level is still low, to ensure that the detected falling edge
was
> a Start bit not a noise spike. Another common improvement is to
> sample each bit not simply once at the mid bit position (clock
count
> 8 out of 16), but three times (clock counts 7, 8, and 9 out of
16)."
> From Philips SCC2691_2.pdf UART note:
>
> "The receiver has a digital filter designed to reject "noisy" data
> transitions and the receiver state machine was designed to reject
> noisy start bits or noise that might be considered a start bit."
>
> From TI TL16PIR552:
>
> "The UART tries to resynchronize after a framing error. To
accomplish
> this, it is assumed that the framing error is due to the next
start
> bit. The UART samples this start bit twice and then accepts the
input
> data..... The next character transfer is enabled after SIN goes to
> the marking state for at least two RCLK samples and then receives
the
> next valid start bit."
>
> Intersil 82C50A:
>
> "Verifying the start bit prevents the receiver from assembling an
> incorrect data character due to a low going noise spike on the SIN
> input."
> These 2 are from other forums but is relative to noise in the non
> start bits bits too. We did this at my last job with those 10
> software UARTS:
>
> 1)
> "Many UART chips use the 16x clock to sample the RxD pin multiple
> times for every bit, then they use a majority algorithm to
determine
> the final state of the bit (in case all samples don't agree)."
>
> 2)
> "Before a start bit is recognized, you look for a couple of
> consecutive mark samples (typically 3 or 4) before deciding
> that it really is a start bit. THis kills noise effects. Then
> sample at the bit mid points (the start bit mid point would be 4
or 5
> clocks from the detection of the start in a 16x system). Sample
> again every 16th clock to read the midpoints of the bits. If you
> want to get fancier, you can sense several of the samples around
the
> mid points and vote on the level for a little more noise immunity."
> etc....
> boB
>
Brendan
--- In l..., "bobtransformer" wrote:
>
> --- In l..., "jayasooriah" wrote:
> >>
> > Over sampling in UARTs determines sampling timer resolution and
has
> > nothing to do with filtering noise or spikes as the original post
> > suggested, or any 'generic' sense as it like to believe.
> >
> > Designers of UARTs know the difference between timing the frame
and
> > filtering.
> >
> > Jaya
> > In addition to timing resolution, the oversampling is handy
> to use for "debouncing" of the data, as I like to think of it.
> Not "filtering", as in low pass of course, but mainly False Start-
Bit
> Detection. That's the most important point I think but this can
> also be applied to the other bits where an average is taken over
> the samples during the middle of the bit times and a vote is taken.
> Here's some False Start-Bit Detection notes:
>
> For instance, from Maxim:
>
> http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/
>
> "The Start bit is typically sampled at the mid bit time to check
that
> the level is still low, to ensure that the detected falling edge
was
> a Start bit not a noise spike. Another common improvement is to
> sample each bit not simply once at the mid bit position (clock
count
> 8 out of 16), but three times (clock counts 7, 8, and 9 out of
16)."
> From Philips SCC2691_2.pdf UART note:
>
> "The receiver has a digital filter designed to reject "noisy" data
> transitions and the receiver state machine was designed to reject
> noisy start bits or noise that might be considered a start bit."
>
> From TI TL16PIR552:
>
> "The UART tries to resynchronize after a framing error. To
accomplish
> this, it is assumed that the framing error is due to the next
start
> bit. The UART samples this start bit twice and then accepts the
input
> data..... The next character transfer is enabled after SIN goes to
> the marking state for at least two RCLK samples and then receives
the
> next valid start bit."
>
> Intersil 82C50A:
>
> "Verifying the start bit prevents the receiver from assembling an
> incorrect data character due to a low going noise spike on the SIN
> input."
> These 2 are from other forums but is relative to noise in the non
> start bits bits too. We did this at my last job with those 10
> software UARTS:
>
> 1)
> "Many UART chips use the 16x clock to sample the RxD pin multiple
> times for every bit, then they use a majority algorithm to
determine
> the final state of the bit (in case all samples don't agree)."
>
> 2)
> "Before a start bit is recognized, you look for a couple of
> consecutive mark samples (typically 3 or 4) before deciding
> that it really is a start bit. THis kills noise effects. Then
> sample at the bit mid points (the start bit mid point would be 4
or 5
> clocks from the detection of the start in a 16x system). Sample
> again every 16th clock to read the midpoints of the bits. If you
> want to get fancier, you can sense several of the samples around
the
> mid points and vote on the level for a little more noise immunity."
> etc....
> boB
>
Reply by ●October 8, 20062006-10-08
Hi,
I am not sure who asked for me to test the software uart in loopback
mode to check for errors.. I did it sending a series from 0 to 255 to make
it easy to check and also made the generation of the sequence using the same
timer interrupt and also coming from another board to make it asynchronous
and both ran for some hours with zero erros...
I can't tell you how relieved that makes me fell :-) Oversampling and
redundancy is nice to have but not essential if your higher level protocol
can handle some errors once in a while. In a clean, noiseless environment it
is not necessary.
There was one piece of information on the discussion that is really nice
and can be quite easy to implement even with 3x bit rate sampling... You can
double check for the start bit, that would make just one more state in the
state machine. Cheap and easy to implement. I will make that when I recode
the routines for the ARM...
Best regards,
Alexandre Guimaraes
I am not sure who asked for me to test the software uart in loopback
mode to check for errors.. I did it sending a series from 0 to 255 to make
it easy to check and also made the generation of the sequence using the same
timer interrupt and also coming from another board to make it asynchronous
and both ran for some hours with zero erros...
I can't tell you how relieved that makes me fell :-) Oversampling and
redundancy is nice to have but not essential if your higher level protocol
can handle some errors once in a while. In a clean, noiseless environment it
is not necessary.
There was one piece of information on the discussion that is really nice
and can be quite easy to implement even with 3x bit rate sampling... You can
double check for the start bit, that would make just one more state in the
state machine. Cheap and easy to implement. I will make that when I recode
the routines for the ARM...
Best regards,
Alexandre Guimaraes
Reply by ●October 8, 20062006-10-08
--- In l..., Alexandre Guimars
wrote:
>
> Hi,
>
> I am not sure who asked for me to test the software uart in
loopback
> mode to check for errors.. I did it sending a series from 0 to 255
to make
> it easy to check and also made the generation of the sequence
using the same
> timer interrupt and also coming from another board to make it
asynchronous
> and both ran for some hours with zero erros...
>
> I can't tell you how relieved that makes me fell :-)
Oversampling and
> redundancy is nice to have but not essential if your higher level
protocol
> can handle some errors once in a while. In a clean, noiseless
environment it
> is not necessary.
>
> There was one piece of information on the discussion that is
really nice
> and can be quite easy to implement even with 3x bit rate
sampling... You can
> double check for the start bit, that would make just one more
state in the
> state machine. Cheap and easy to implement. I will make that when
I recode
> the routines for the ARM...
>
> Best regards,
> Alexandre Guimaraes
>
Alexandre,
I owe you something of an apology.
My concern was that if the sender's and receiver's clocks differed,
the sampling error would accumulate over the length of the character
to give misread bits at the end if 3x sampling was used.
The problem was I didn't take into account in my back of the
envelope calculation that the start bit detection moves all the
samples around in time (i.e. the start point shifts). It turns out
the clocks have to differ by about 7% for a misread bit to happen
with 3x sampling.
As this is quite a lot, I'd agree with you: for most cases 3x should
be enough. Sorry if I caused you any unnecessary concern!
Regards
Brendan
wrote:
>
> Hi,
>
> I am not sure who asked for me to test the software uart in
loopback
> mode to check for errors.. I did it sending a series from 0 to 255
to make
> it easy to check and also made the generation of the sequence
using the same
> timer interrupt and also coming from another board to make it
asynchronous
> and both ran for some hours with zero erros...
>
> I can't tell you how relieved that makes me fell :-)
Oversampling and
> redundancy is nice to have but not essential if your higher level
protocol
> can handle some errors once in a while. In a clean, noiseless
environment it
> is not necessary.
>
> There was one piece of information on the discussion that is
really nice
> and can be quite easy to implement even with 3x bit rate
sampling... You can
> double check for the start bit, that would make just one more
state in the
> state machine. Cheap and easy to implement. I will make that when
I recode
> the routines for the ARM...
>
> Best regards,
> Alexandre Guimaraes
>
Alexandre,
I owe you something of an apology.
My concern was that if the sender's and receiver's clocks differed,
the sampling error would accumulate over the length of the character
to give misread bits at the end if 3x sampling was used.
The problem was I didn't take into account in my back of the
envelope calculation that the start bit detection moves all the
samples around in time (i.e. the start point shifts). It turns out
the clocks have to differ by about 7% for a misread bit to happen
with 3x sampling.
As this is quite a lot, I'd agree with you: for most cases 3x should
be enough. Sorry if I caused you any unnecessary concern!
Regards
Brendan
