I am working on a project that is part of an RS485 bus running at 38400
baud. I've discovered something odd.
Background
------------
I needed to determine incoming break generated by master. Protocol is
two breaks, then data stream.
Setup
------------
LPC2103 Board has a 14745600 crystal.
Using my tool lpc2fdcalc.exe to come up with fractional divider register
values.
I'm listening to RS485 bus on Uart1 @ 38400 and forwarding data to Uart0
@ 115200.
Scenario
------------
Running Peripheral clock at 4x fundamental and selecting the following
from lpc2fdcalc I get null characters:
DLM DLL MULVAL DIVADDVAL Actual % Err
--- --- ------ --------- --------- --------
0 6 1 15 38400.00 0.000000
If I select combination with higher DLL it works, and I see proper data:
DLM DLL MULVAL DIVADDVAL Actual % Err
--- --- ------ --------- --------- --------
0 54 9 7 38400.00 0.000000
Ok on to attempting to trap a break signal.
No luck on the break, and I was finding continual frame errors, break
interrupt, etc. So I put a counter in each event. Something like this:
dummy = U1LSR; /* Just clear the interrupt source */
if((dummy & 0x02) == 0x02) { // overrun error
over = over + 1;
}
if((dummy & 0x04) == 0x04) { // parity error
parity = parity + 1;
}
if((dummy & 0x08) == 0x08) { // framing error
frame = frame + 1;
}
if((dummy & 0x10) == 0x10) { // break interrupt
brk = brk + 1;
}
if((dummy & 0x80) == 0x80) { // fifo rx contains at least 1
rx error
fifoerr = fifoerr + 1;
}
Now this is what's strange. Depending on what fractional divider values
I use, I end up with different count values. Then to spice things up I
started playing with the PLL and PCLK speed. All of this has an affect
of the count value totals. I am sending a ~3k byte block from RS485
master. I can send this same block as many times as I want, and end up
with identical count values. If I twiddle the PLL, PCLK, or Fractional
divider and re-send stream I end up with different count values; with
repeatable results.
Example count values:
38400 // 0,54,9,7
-----------
1894 - frame
1546 - brk
1894 - fifo err
0 - overrun
0 - parity
Has anyone else been able to reliably detect a break or frame error with
LPC2103?
If I'm missing something please point it out.
Thanks,
Joel Winarske
www.indyelectronics.com
LPC2103 RS485 Break/Frame Error Detect
Started by ●September 24, 2006
Reply by ●September 24, 20062006-09-24
--- In l..., Joel Winarske wrote:
>
> I am working on a project that is part of an RS485 bus running at
38400
> baud. I've discovered something odd.
>
> Background
> ------------
> I needed to determine incoming break generated by master.
Protocol is
> two breaks, then data stream.
>
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
> Using my tool lpc2fdcalc.exe to come up with fractional divider
register
> values.
> I'm listening to RS485 bus on Uart1 @ 38400 and forwarding data to
Uart0
> @ 115200.
>
> Scenario
> ------------
> Running Peripheral clock at 4x fundamental and selecting the
following
> from lpc2fdcalc I get null characters:
>
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 6 1 15 38400.00 0.000000
>
> If I select combination with higher DLL it works, and I see proper
data:
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 54 9 7 38400.00 0.000000
>
> Ok on to attempting to trap a break signal.
>
> No luck on the break, and I was finding continual frame errors,
break
> interrupt, etc. So I put a counter in each event. Something like
this:
>
> dummy = U1LSR; /* Just clear the interrupt source */
>
> if((dummy & 0x02) == 0x02) { // overrun error
> over = over + 1;
> }
> if((dummy & 0x04) == 0x04) { // parity error
> parity = parity + 1;
> }
> if((dummy & 0x08) == 0x08) { // framing error
> frame = frame + 1;
> }
> if((dummy & 0x10) == 0x10) { // break interrupt
> brk = brk + 1;
> }
> if((dummy & 0x80) == 0x80) { // fifo rx contains at
least 1
> rx error
> fifoerr = fifoerr + 1;
> }
>
> Now this is what's strange. Depending on what fractional divider
values
> I use, I end up with different count values. Then to spice things
up I
> started playing with the PLL and PCLK speed. All of this has an
affect
> of the count value totals. I am sending a ~3k byte block from
RS485
> master. I can send this same block as many times as I want, and
end up
> with identical count values. If I twiddle the PLL, PCLK, or
Fractional
> divider and re-send stream I end up with different count values;
with
> repeatable results.
>
> Example count values:
> 38400 // 0,54,9,7
> -----------
> 1894 - frame
> 1546 - brk
> 1894 - fifo err
> 0 - overrun
> 0 - parity
>
> Has anyone else been able to reliably detect a break or frame
error with
> LPC2103?
>
> If I'm missing something please point it out.
>
Joel,
I'd look carefully at the UART config values you're using.
A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
unless I'm misreadimg something or have miscalculated. I haven't
checked the other values you quote.
To answer your question, yes I've seen break detect work OK.
A couple of other points:
- have you read the errata for the part?
- note that only come combinations of M and P are valid for PLL
configuration
- it might be quite difficult to detect two breaks and then data
with a regular UART, depending on the timing. You might want to
consider some other technique to detect the pre-amble and then
switch to using the UART
- if at all possible, I'd recommend getting the data parts
functioning well before introducing the break feature
I hope this helps.
Brendan
>
> I am working on a project that is part of an RS485 bus running at
38400
> baud. I've discovered something odd.
>
> Background
> ------------
> I needed to determine incoming break generated by master.
Protocol is
> two breaks, then data stream.
>
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
> Using my tool lpc2fdcalc.exe to come up with fractional divider
register
> values.
> I'm listening to RS485 bus on Uart1 @ 38400 and forwarding data to
Uart0
> @ 115200.
>
> Scenario
> ------------
> Running Peripheral clock at 4x fundamental and selecting the
following
> from lpc2fdcalc I get null characters:
>
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 6 1 15 38400.00 0.000000
>
> If I select combination with higher DLL it works, and I see proper
data:
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 54 9 7 38400.00 0.000000
>
> Ok on to attempting to trap a break signal.
>
> No luck on the break, and I was finding continual frame errors,
break
> interrupt, etc. So I put a counter in each event. Something like
this:
>
> dummy = U1LSR; /* Just clear the interrupt source */
>
> if((dummy & 0x02) == 0x02) { // overrun error
> over = over + 1;
> }
> if((dummy & 0x04) == 0x04) { // parity error
> parity = parity + 1;
> }
> if((dummy & 0x08) == 0x08) { // framing error
> frame = frame + 1;
> }
> if((dummy & 0x10) == 0x10) { // break interrupt
> brk = brk + 1;
> }
> if((dummy & 0x80) == 0x80) { // fifo rx contains at
least 1
> rx error
> fifoerr = fifoerr + 1;
> }
>
> Now this is what's strange. Depending on what fractional divider
values
> I use, I end up with different count values. Then to spice things
up I
> started playing with the PLL and PCLK speed. All of this has an
affect
> of the count value totals. I am sending a ~3k byte block from
RS485
> master. I can send this same block as many times as I want, and
end up
> with identical count values. If I twiddle the PLL, PCLK, or
Fractional
> divider and re-send stream I end up with different count values;
with
> repeatable results.
>
> Example count values:
> 38400 // 0,54,9,7
> -----------
> 1894 - frame
> 1546 - brk
> 1894 - fifo err
> 0 - overrun
> 0 - parity
>
> Has anyone else been able to reliably detect a break or frame
error with
> LPC2103?
>
> If I'm missing something please point it out.
>
Joel,
I'd look carefully at the UART config values you're using.
A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
unless I'm misreadimg something or have miscalculated. I haven't
checked the other values you quote.
To answer your question, yes I've seen break detect work OK.
A couple of other points:
- have you read the errata for the part?
- note that only come combinations of M and P are valid for PLL
configuration
- it might be quite difficult to detect two breaks and then data
with a regular UART, depending on the timing. You might want to
consider some other technique to detect the pre-amble and then
switch to using the UART
- if at all possible, I'd recommend getting the data parts
functioning well before introducing the break feature
I hope this helps.
Brendan
Reply by ●September 24, 20062006-09-24
---- Original Message ----
From: "Joel Winarske"
To:
Sent: Sunday, September 24, 2006 11:14 AM
Subject: [lpc2000] LPC2103 RS485 Break/Frame Error Detect
> I am working on a project that is part of an RS485 bus running at
> 38400 baud. I've discovered something odd.
>
> Background
> ------------
> I needed to determine incoming break generated by master. Protocol is
> two breaks, then data stream.
>
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
> Using my tool lpc2fdcalc.exe to come up with fractional divider
> register values.
> I'm listening to RS485 bus on Uart1 @ 38400 and forwarding data to
> Uart0 @ 115200.
>
> Scenario
> ------------
> Running Peripheral clock at 4x fundamental and selecting the following
> from lpc2fdcalc I get null characters:
>
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 6 1 15 38400.00 0.000000
>
> If I select combination with higher DLL it works, and I see proper
> data: DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 54 9 7 38400.00 0.000000
>
> Ok on to attempting to trap a break signal.
>
> No luck on the break, and I was finding continual frame errors, break
> interrupt, etc. So I put a counter in each event. Something like
> this:
>
> dummy = U1LSR; /* Just clear the interrupt source */
>
> if((dummy & 0x02) == 0x02) { // overrun error
> over = over + 1;
> }
> if((dummy & 0x04) == 0x04) { // parity error
> parity = parity + 1;
> }
> if((dummy & 0x08) == 0x08) { // framing error
> frame = frame + 1;
> }
> if((dummy & 0x10) == 0x10) { // break interrupt
> brk = brk + 1;
> }
> if((dummy & 0x80) == 0x80) { // fifo rx contains at least 1
> rx error
> fifoerr = fifoerr + 1;
> }
>
> Now this is what's strange. Depending on what fractional divider
> values I use, I end up with different count values. Then to spice
> things up I started playing with the PLL and PCLK speed. All of this
> has an affect of the count value totals. I am sending a ~3k byte
> block from RS485 master. I can send this same block as many times as
> I want, and end up with identical count values. If I twiddle the
> PLL, PCLK, or Fractional divider and re-send stream I end up with
> different count values; with repeatable results.
>
> Example count values:
> 38400 // 0,54,9,7
> -----------
> 1894 - frame
> 1546 - brk
> 1894 - fifo err
> 0 - overrun
> 0 - parity
>
> Has anyone else been able to reliably detect a break or frame error
> with LPC2103?
I guess there are limitations or bugs concerning the fractional baudrate
divider that Phi^H^H^HNXP hasn't told about.
http://tech.groups.yahoo.com/group/lpc2000/message/12520
Karl Olsen
From: "Joel Winarske"
To:
Sent: Sunday, September 24, 2006 11:14 AM
Subject: [lpc2000] LPC2103 RS485 Break/Frame Error Detect
> I am working on a project that is part of an RS485 bus running at
> 38400 baud. I've discovered something odd.
>
> Background
> ------------
> I needed to determine incoming break generated by master. Protocol is
> two breaks, then data stream.
>
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
> Using my tool lpc2fdcalc.exe to come up with fractional divider
> register values.
> I'm listening to RS485 bus on Uart1 @ 38400 and forwarding data to
> Uart0 @ 115200.
>
> Scenario
> ------------
> Running Peripheral clock at 4x fundamental and selecting the following
> from lpc2fdcalc I get null characters:
>
> DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 6 1 15 38400.00 0.000000
>
> If I select combination with higher DLL it works, and I see proper
> data: DLM DLL MULVAL DIVADDVAL Actual % Err
> --- --- ------ --------- --------- --------
> 0 54 9 7 38400.00 0.000000
>
> Ok on to attempting to trap a break signal.
>
> No luck on the break, and I was finding continual frame errors, break
> interrupt, etc. So I put a counter in each event. Something like
> this:
>
> dummy = U1LSR; /* Just clear the interrupt source */
>
> if((dummy & 0x02) == 0x02) { // overrun error
> over = over + 1;
> }
> if((dummy & 0x04) == 0x04) { // parity error
> parity = parity + 1;
> }
> if((dummy & 0x08) == 0x08) { // framing error
> frame = frame + 1;
> }
> if((dummy & 0x10) == 0x10) { // break interrupt
> brk = brk + 1;
> }
> if((dummy & 0x80) == 0x80) { // fifo rx contains at least 1
> rx error
> fifoerr = fifoerr + 1;
> }
>
> Now this is what's strange. Depending on what fractional divider
> values I use, I end up with different count values. Then to spice
> things up I started playing with the PLL and PCLK speed. All of this
> has an affect of the count value totals. I am sending a ~3k byte
> block from RS485 master. I can send this same block as many times as
> I want, and end up with identical count values. If I twiddle the
> PLL, PCLK, or Fractional divider and re-send stream I end up with
> different count values; with repeatable results.
>
> Example count values:
> 38400 // 0,54,9,7
> -----------
> 1894 - frame
> 1546 - brk
> 1894 - fifo err
> 0 - overrun
> 0 - parity
>
> Has anyone else been able to reliably detect a break or frame error
> with LPC2103?
I guess there are limitations or bugs concerning the fractional baudrate
divider that Phi^H^H^HNXP hasn't told about.
http://tech.groups.yahoo.com/group/lpc2000/message/12520
Karl Olsen
Reply by ●September 24, 20062006-09-24
Hi Brandon,
> I'd look carefully at the UART config values you're using.
>
> A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
> clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
> unless I'm misreadimg something or have miscalculated. I haven't
> checked the other values you quote.
>
These values are referenced with PCLK at 58.9824 MHz. I am pointing out
various combinations yield different results.
lpc2fdcalc Output:
"
D:\dev\Philips\LPC2000>lpc2fdcalc
LPC2000 UART Fractional Divider Calculator v1.1
foward comments to j...@indyelectronics.com
Enter PCLK in Hz=> 58982400
Enter Desired Baudrate=> 38400
Max Result Count=> 5
PCLK: 58982400 Hz
Desired Baud: 38400.00
Max Result Count: 5
Is this correct?=> y
Standby...
DLM DLL MULVAL DIVADDVAL Actual % Err
--- --- ------ --------- --------- --------
0 6 1 15 38400.00 0.000000
0 54 9 7 38400.00 0.000000
0 84 7 1 38400.00 0.000000
0 12 1 7 38400.00 0.000000
0 12 2 14 38400.00 0.000000
0 72 6 2 38400.00 0.000000
"
> To answer your question, yes I've seen break detect work OK.
>
> A couple of other points:
>
> - have you read the errata for the part?
>
Yes. SPI, MAM, and Timer are only referenced. Nothing is mentioned
about the UART.
What baud rate have you seen break detect work on the LPC2103?
> - note that only come combinations of M and P are valid for PLL
> configuration
>
Yes this is apparent. I've experienced this before at low baud rates
with the LPC2148, one case I ran across during testing was 300 baud.
Perhaps I might go back and try larger another combination with a larger
DLL value.
> - it might be quite difficult to detect two breaks and then data
> with a regular UART, depending on the timing. You might want to
> consider some other technique to detect the pre-amble and then
> switch to using the UART
> - if at all possible, I'd recommend getting the data parts
> functioning well before introducing the break feature
>
I have the data part working fine. Even though I am seeing error counts
the ~3k bytes are 100% correct on the receiving end..
This is the discrepancy. If I see error counts I should see
inconsistent data..
> I hope this helps.
>
It's a start.
Joel
> I'd look carefully at the UART config values you're using.
>
> A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
> clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
> unless I'm misreadimg something or have miscalculated. I haven't
> checked the other values you quote.
>
These values are referenced with PCLK at 58.9824 MHz. I am pointing out
various combinations yield different results.
lpc2fdcalc Output:
"
D:\dev\Philips\LPC2000>lpc2fdcalc
LPC2000 UART Fractional Divider Calculator v1.1
foward comments to j...@indyelectronics.com
Enter PCLK in Hz=> 58982400
Enter Desired Baudrate=> 38400
Max Result Count=> 5
PCLK: 58982400 Hz
Desired Baud: 38400.00
Max Result Count: 5
Is this correct?=> y
Standby...
DLM DLL MULVAL DIVADDVAL Actual % Err
--- --- ------ --------- --------- --------
0 6 1 15 38400.00 0.000000
0 54 9 7 38400.00 0.000000
0 84 7 1 38400.00 0.000000
0 12 1 7 38400.00 0.000000
0 12 2 14 38400.00 0.000000
0 72 6 2 38400.00 0.000000
"
> To answer your question, yes I've seen break detect work OK.
>
> A couple of other points:
>
> - have you read the errata for the part?
>
Yes. SPI, MAM, and Timer are only referenced. Nothing is mentioned
about the UART.
What baud rate have you seen break detect work on the LPC2103?
> - note that only come combinations of M and P are valid for PLL
> configuration
>
Yes this is apparent. I've experienced this before at low baud rates
with the LPC2148, one case I ran across during testing was 300 baud.
Perhaps I might go back and try larger another combination with a larger
DLL value.
> - it might be quite difficult to detect two breaks and then data
> with a regular UART, depending on the timing. You might want to
> consider some other technique to detect the pre-amble and then
> switch to using the UART
> - if at all possible, I'd recommend getting the data parts
> functioning well before introducing the break feature
>
I have the data part working fine. Even though I am seeing error counts
the ~3k bytes are 100% correct on the receiving end..
This is the discrepancy. If I see error counts I should see
inconsistent data..
> I hope this helps.
>
It's a start.
Joel
Reply by ●September 24, 20062006-09-24
Karl Olsen wrote:
> I guess there are limitations or bugs concerning the fractional baudrate
> divider that Phi^H^H^HNXP hasn't told about.
>
> http://tech.groups.yahoo.com/group/lpc2000/message/12520
>
I have two different issues:
1. A unidentified range of UxFDR values result in unknown results.
This don't match equation referenced in the user manual.
One thing I haven't done is measure the bit timing for transmission in
this case. This should provide good clue to error parameters.
2. Different FDR register values affect error counting.
My next step is to test without UxFDR enabled.
Thanks for triggering the thought Karl.
Joel
> I guess there are limitations or bugs concerning the fractional baudrate
> divider that Phi^H^H^HNXP hasn't told about.
>
> http://tech.groups.yahoo.com/group/lpc2000/message/12520
>
I have two different issues:
1. A unidentified range of UxFDR values result in unknown results.
This don't match equation referenced in the user manual.
One thing I haven't done is measure the bit timing for transmission in
this case. This should provide good clue to error parameters.
2. Different FDR register values affect error counting.
My next step is to test without UxFDR enabled.
Thanks for triggering the thought Karl.
Joel
Reply by ●September 24, 20062006-09-24
--- In l..., Joel Winarske wrote:
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
...
> Has anyone else been able to reliably detect a break or frame error
with
> LPC2103?
Joel, it would be useful to know what happens if you replace the
crystal with one that is not a baud rate multiple.
Reason: One person had 15MHz crystal and could not repeat my results
for UART test. When this was replaced with a 14.7458MHz crystal sure
enough he got exaactly what I got.
Jaya
> Setup
> ------------
> LPC2103 Board has a 14745600 crystal.
...
> Has anyone else been able to reliably detect a break or frame error
with
> LPC2103?
Joel, it would be useful to know what happens if you replace the
crystal with one that is not a baud rate multiple.
Reason: One person had 15MHz crystal and could not repeat my results
for UART test. When this was replaced with a 14.7458MHz crystal sure
enough he got exaactly what I got.
Jaya
Reply by ●September 24, 20062006-09-24
> I have two different issues:
> 1. A unidentified range of UxFDR values result in unknown results.
> This don't match equation referenced in the user manual.
> One thing I haven't done is measure the bit timing for transmission in
> this case. This should provide good clue to error parameters.
>
> 2. Different FDR register values affect error counting.
> My next step is to test without UxFDR enabled.
When I disable UxFDR on the LPC2103 I get zero LSR errors, and I can
detect a break.
Brandon where you've seen break detect working on LPC2103 was the UxFDR
enabled?
Joel
> 1. A unidentified range of UxFDR values result in unknown results.
> This don't match equation referenced in the user manual.
> One thing I haven't done is measure the bit timing for transmission in
> this case. This should provide good clue to error parameters.
>
> 2. Different FDR register values affect error counting.
> My next step is to test without UxFDR enabled.
When I disable UxFDR on the LPC2103 I get zero LSR errors, and I can
detect a break.
Brandon where you've seen break detect working on LPC2103 was the UxFDR
enabled?
Joel
Reply by ●September 24, 20062006-09-24
> Joel, it would be useful to know what happens if you
replace the
> crystal with one that is not a baud rate multiple.
>
> Reason: One person had 15MHz crystal and could not repeat my results
> for UART test. When this was replaced with a 14.7458MHz crystal sure
> enough he got exaactly what I got.
>
Very good question. I will try this with a 12MHz crystal.
Joel
> crystal with one that is not a baud rate multiple.
>
> Reason: One person had 15MHz crystal and could not repeat my results
> for UART test. When this was replaced with a 14.7458MHz crystal sure
> enough he got exaactly what I got.
>
Very good question. I will try this with a 12MHz crystal.
Joel
Reply by ●September 25, 20062006-09-25
--- In l..., Joel Winarske wrote:
>
> Hi Brandon,
> > I'd look carefully at the UART config values you're using.
> >
> > A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
> > clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
> > unless I'm misreadimg something or have miscalculated. I haven't
> > checked the other values you quote.
> >
> These values are referenced with PCLK at 58.9824 MHz.
OK - I clearly misread the 1st part of your message, as I thought
these values referred to 14.7456 MHz.
>
> What baud rate have you seen break detect work on the LPC2103?
>
I can't recall, and unfortuntely can't repeat the test. Almost
certainly either 9.6 or 115.2 kbps, though, as that's what we tend
to use.
In answer to your subsequent question, we've never used the UxFDR
register.
> I have the data part working fine. Even though I am seeing error
counts
This wasn't clear from your original post, which is why I suggested
double checking your config values. Clearly, you're well beyond this
stage, though...
>From what's been said to date, it looks like the UxFDR is worth
investigating further.
Brendan.
>
> Hi Brandon,
> > I'd look carefully at the UART config values you're using.
> >
> > A configuration of DLM=0,DLL=6,DIV,MUL=1 gives 9600bps for a
> > clock of 14.7456 MHz (or 2400 bps if PCLK is CCLK divided by 4),
> > unless I'm misreadimg something or have miscalculated. I haven't
> > checked the other values you quote.
> >
> These values are referenced with PCLK at 58.9824 MHz.
OK - I clearly misread the 1st part of your message, as I thought
these values referred to 14.7456 MHz.
>
> What baud rate have you seen break detect work on the LPC2103?
>
I can't recall, and unfortuntely can't repeat the test. Almost
certainly either 9.6 or 115.2 kbps, though, as that's what we tend
to use.
In answer to your subsequent question, we've never used the UxFDR
register.
> I have the data part working fine. Even though I am seeing error
counts
This wasn't clear from your original post, which is why I suggested
double checking your config values. Clearly, you're well beyond this
stage, though...
>From what's been said to date, it looks like the UxFDR is worth
investigating further.
Brendan.
