Hi Unity0724 and others,

Well, running out of things to try, it's only pulling A hi and B low
that is left to test for now. What values would you recommend? I've
never had any need to so before.

I must say that I've never had this much hard work with normal RS485
ic's from maxim. And getting the TX to work perfect but not the RX is
very frustrating!

It's one of the the few fully isolated RS485 circuits around so there
wasn't much to choose from! Might need to look for alternatives...

Back to testing...

Cheers
Johan
--- In l..., "unity0724" wrote:
>
> For RS485...
>
> - Make sure you pull up A/'+' signal and Pull down B/'-' signal on
> the RS485 bus
> - Make sure you use TEMT to disable your RS485 driver. Do NOT
> disable the RS485 driver immediately after you write the
> character to UART. That character will be slowly shifted out
> and only completed shifting out of the UART when TEMT is set.
> - RS485 is half-duplex, if you do not disable the RS485 receiver
> when transmitting, there will be character echo-ed back to UART
> receiver every time you transmit a character
> - For some RS485 interface parts, there might be "glitches" on the
> bus signal when you disable the RS485 driver (but this normally
> get filtered off by the UART receiver)
>
> Sorry, cannot think of anything else... and Good Luck
> Regards
>
> BTW: I was actually happen to use that MAX1480 in the planning.
> Please give some info of the problem after all this... :)
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi All,
> >
> > Some comments back on my own post.
> >
> > I have tried with blinking a led every time I'm supposed to
> received a
> > char and that LED is blinking rock solid (even if it doesn't say if
> > it's a correct received char ;-) ).
> >
> > Second, I tested against a RS-232 chip instead and it was rock
> solid
> > echoing of the char I sent to it so I presume, once again, that the
> > actual code for receiving and sending is ok and it's something with
> > timing or simular that makes it go wrong when using the RS485 chip.
> >
> > As I can send without any problem it looks like, and I have
> verified
> > the schema/pcb many times now, the connections between LPC2106 and
> the
> > MAXIM circuit should be fine.
> >
> > So, doing a test with interrupt handling on the comms RX part
> could be
> > worth it. Shall have a look at the errata also.
> >
> > Someone here that have worked with the MAX1480B chip?
> >
> > Thanks for all the input and comments so far. Anything more of
> ideas
> > or thoughts are, as before, very very welcome.
> >
> > Cheers
> > /Johan
> >
> > --- In l..., "fredrikssonjohan" wrote:
> > >
> > > Hi!
> > >
> > > I'm stucked with this and can't figure out why it will not work.
> > > Anyone seeing the obvious or have any friendly ideas of what
> might be
> > > wrong?
> > >
> > > OK. I'll try to give an as good description as possible of what
> I have
> > > and try do. The first problem is that if I send, as a test,
> 8 "A" I
> > > will get 4 or 5 "A"s in return and then one or two non ascii
> visible
> > > chars and mostly a FF as end. I would say the successrate is 3-4
> per
> > > 20 sent blocks of 8 "A". So there is my problem. No clean RX on
> the
> > > LPC2106 with this MAX1480B.
> > >
> > > There is a LPC2106 connected via a 74HC86 and finally the Maxim
> > > MAX1480B opto/power isolated circuit. This is all connected as
> per
> > > MAXIMSs datasheet and work 100% when sending data. Never miss a
> single
> > > bit.
> > > As I never have any TX problem I figure that the init part of
> the port
> > > should be OK.
> > >
> > > As a stripped down testing routine I do the following:
> > > while (1)
> > > {
> > > cbuff[icnt] = wait_and_receive();
> > > icnt++;
> > >
> > > if (icnt == 8)
> > > {
> > > icnt = 0;
> > > IOSET = (1< > > > pause(TWO_MS);
> > > for (int j = 0; j < 8; j++)
> > > uart1Putch(cbuff[j]);
> > >
> > > // Back to RX mode again
> > > IOCLR = (1< > > > pause(TWO_MS);
> > > }
> > > }
> > >
> > > Im just waiting for any char in the RX buffer and switch to
> RS486 TX
> > > mode and send it back. Added a small delay after switching mode
> on the
> > > RS485 line just to be sure.
> > >
> > > Using this bit just for pool until there is a char available
> > > int wait_and_receive(void)
> > > {
> > > int ch;
> > >
> > > while((ch = uart1Getch()) == -1) {
> > > ;
> > > }
> > > return ch;
> > > }
> > >
> > > And this is the actual code checking if the is a char available.
> > > The uart1Getch(...) loooks like this:
> > > if (U1LSR & ULSR_RDR) // check if character is available
> > > return U1RBR; // return character
> > > return -1;
> > >
> > > The init is done by this and works perfect for TX
> > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > {
> > > // set port pins for UART1
> > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > >
> > > U1IER = 0x00; // disable all interrupts
> > > U1IIR; // clear interrupt ID
> > > U1RBR; // clear receive register
> > > U1LSR; // clear line status
> register
> > >
> > > // set the baudrate
> > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> latches
> > > U1DLL = (uint8_t)baud; // set for baud low byte
> > > U1DLM = (uint8_t)(baud >> 8); // set for baud high byte
> > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > U1FCR = fmode;
> > > }
> > >
> > > Wow, sorry for the long message and code, but otherwise I guess
> > > someone is asking how that and that is done so I include it from
> the
> > > start.
> > >
> > > If anyone have a clue or idea I would be very happy guy!
> > >
> > > Cheers
> > > Johan
> > >
> Start a New Thread

Hi,
For pull up, I use 20KR if there are heavy loading of 32x
devices (Sometimes actually overloading up to >50 ...out
of spec), and 3.3KR if only point to point. All these
were done on SN75176, not MAX1480.

It might help your debugging if you could remove that
MAX1480 and wire a simple SN75176 to get software
working first. The opto-coupler Hi-V isolation should
be "fully transparent" to your software. If it works on a
simple SN75176, it should work on MAX1480.

For MAX1480 debugging, could you find some way to
disable that DC-DC isolated supply converter.... :)
and inject some regulated power supply first.

Sorry, Cannot think of anything else.... :)

I was thinking of using ADM2483 instead of MAX1480.
DigiKey is unable to ship any Maxim or LinearTech parts
to Singapore here (...sales boundary...) and having some
problem with prototyping qty. ADM2483 is cheaper
(after external DC-DC Converter included), looks very much
like a SN75176, plus I also do not really like that MAX1480.

Have not read the MAX1480 in detail. Let me do that later
and see if I can provide you some debugging aids...

...Have fun.. and good luck... :)
Regards

--- In l..., "fredrikssonjohan" wrote:
>
> Hi Unity0724 and others,
>
> Well, running out of things to try, it's only pulling A hi and B
low
> that is left to test for now. What values would you recommend? I've
> never had any need to so before.
>
> I must say that I've never had this much hard work with normal
RS485
> ic's from maxim. And getting the TX to work perfect but not the RX
is
> very frustrating!
>
> It's one of the the few fully isolated RS485 circuits around so
there
> wasn't much to choose from! Might need to look for alternatives...
>
> Back to testing...
>
> Cheers
> Johan
> --- In l..., "unity0724" wrote:
> >
> > For RS485...
> >
> > - Make sure you pull up A/'+' signal and Pull down B/'-' signal
on
> > the RS485 bus
> > - Make sure you use TEMT to disable your RS485 driver. Do NOT
> > disable the RS485 driver immediately after you write the
> > character to UART. That character will be slowly shifted out
> > and only completed shifting out of the UART when TEMT is set.
> > - RS485 is half-duplex, if you do not disable the RS485 receiver
> > when transmitting, there will be character echo-ed back to UART
> > receiver every time you transmit a character
> > - For some RS485 interface parts, there might be "glitches" on
the
> > bus signal when you disable the RS485 driver (but this normally
> > get filtered off by the UART receiver)
> >
> > Sorry, cannot think of anything else... and Good Luck
> > Regards
> >
> > BTW: I was actually happen to use that MAX1480 in the planning.
> > Please give some info of the problem after all this... :)
> >
> >
> >
> > --- In l..., "fredrikssonjohan"
wrote:
> > >
> > > Hi All,
> > >
> > > Some comments back on my own post.
> > >
> > > I have tried with blinking a led every time I'm supposed to
> > received a
> > > char and that LED is blinking rock solid (even if it doesn't
say if
> > > it's a correct received char ;-) ).
> > >
> > > Second, I tested against a RS-232 chip instead and it was rock
> > solid
> > > echoing of the char I sent to it so I presume, once again,
that the
> > > actual code for receiving and sending is ok and it's something
with
> > > timing or simular that makes it go wrong when using the RS485
chip.
> > >
> > > As I can send without any problem it looks like, and I have
> > verified
> > > the schema/pcb many times now, the connections between LPC2106
and
> > the
> > > MAXIM circuit should be fine.
> > >
> > > So, doing a test with interrupt handling on the comms RX part
> > could be
> > > worth it. Shall have a look at the errata also.
> > >
> > > Someone here that have worked with the MAX1480B chip?
> > >
> > > Thanks for all the input and comments so far. Anything more of
> > ideas
> > > or thoughts are, as before, very very welcome.
> > >
> > > Cheers
> > > /Johan
> > >
> > > --- In l..., "fredrikssonjohan"
wrote:
> > > >
> > > > Hi!
> > > >
> > > > I'm stucked with this and can't figure out why it will not
work.
> > > > Anyone seeing the obvious or have any friendly ideas of what
> > might be
> > > > wrong?
> > > >
> > > > OK. I'll try to give an as good description as possible of
what
> > I have
> > > > and try do. The first problem is that if I send, as a test,
> > 8 "A" I
> > > > will get 4 or 5 "A"s in return and then one or two non ascii
> > visible
> > > > chars and mostly a FF as end. I would say the successrate is
3-4
> > per
> > > > 20 sent blocks of 8 "A". So there is my problem. No clean RX
on
> > the
> > > > LPC2106 with this MAX1480B.
> > > >
> > > > There is a LPC2106 connected via a 74HC86 and finally the
Maxim
> > > > MAX1480B opto/power isolated circuit. This is all connected
as
> > per
> > > > MAXIMSs datasheet and work 100% when sending data. Never
miss a
> > single
> > > > bit.
> > > > As I never have any TX problem I figure that the init part
of
> > the port
> > > > should be OK.
> > > >
> > > > As a stripped down testing routine I do the following:
> > > > while (1)
> > > > {
> > > > cbuff[icnt] = wait_and_receive();
> > > > icnt++;
> > > >
> > > > if (icnt == 8)
> > > > {
> > > > icnt = 0;
> > > > IOSET = (1< > > > > pause(TWO_MS);
> > > > for (int j = 0; j < 8; j++)
> > > > uart1Putch(cbuff[j]);
> > > >
> > > > // Back to RX mode again
> > > > IOCLR = (1< > > > > pause(TWO_MS);
> > > > }
> > > > }
> > > >
> > > > Im just waiting for any char in the RX buffer and switch to
> > RS486 TX
> > > > mode and send it back. Added a small delay after switching
mode
> > on the
> > > > RS485 line just to be sure.
> > > >
> > > > Using this bit just for pool until there is a char available
> > > > int wait_and_receive(void)
> > > > {
> > > > int ch;
> > > >
> > > > while((ch = uart1Getch()) == -1) {
> > > > ;
> > > > }
> > > > return ch;
> > > > }
> > > >
> > > > And this is the actual code checking if the is a char
available.
> > > > The uart1Getch(...) loooks like this:
> > > > if (U1LSR & ULSR_RDR) // check if character is available
> > > > return U1RBR; // return character
> > > > return -1;
> > > >
> > > > The init is done by this and works perfect for TX
> > > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > > {
> > > > // set port pins for UART1
> > > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > > >
> > > > U1IER = 0x00; // disable all
interrupts
> > > > U1IIR; // clear interrupt ID
> > > > U1RBR; // clear receive
register
> > > > U1LSR; // clear line status
> > register
> > > >
> > > > // set the baudrate
> > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> > latches
> > > > U1DLL = (uint8_t)baud; // set for baud low
byte
> > > > U1DLM = (uint8_t)(baud >> 8); // set for baud high
byte
> > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > U1FCR = fmode;
> > > > }
> > > >
> > > > Wow, sorry for the long message and code, but otherwise I
guess
> > > > someone is asking how that and that is done so I include it
from
> > the
> > > > start.
> > > >
> > > > If anyone have a clue or idea I would be very happy guy!
> > > >
> > > > Cheers
> > > > Johan
> > > >
> > >
> Start a New Thread

OK,
Disabling the DC-DC Converter of MAX1480:
- Measure Voltage of PIN 26
- Disconnect PIN1 & PIN2 (May be PIN 8 also) from VCC
- Inject same measured voltage to PIN26, attach
a bigger decoupling capacitor. Take note of capacitor
should be connecting to that RS485 floating ground.

=> Pls don't blame me if your MAX1480/LPC2106 burnt
=> Have fun... and good luck..

BTW: May be you should short your LPC2106 ground to the
RS485 Isolated ground first. Remove possiblity of some
components not conected to the correct ground...

Regards

--- In l..., "unity0724" wrote:
>
> Hi,
> For pull up, I use 20KR if there are heavy loading of 32x
> devices (Sometimes actually overloading up to >50 ...out
> of spec), and 3.3KR if only point to point. All these
> were done on SN75176, not MAX1480.
>
> It might help your debugging if you could remove that
> MAX1480 and wire a simple SN75176 to get software
> working first. The opto-coupler Hi-V isolation should
> be "fully transparent" to your software. If it works on a
> simple SN75176, it should work on MAX1480.
>
> For MAX1480 debugging, could you find some way to
> disable that DC-DC isolated supply converter.... :)
> and inject some regulated power supply first.
>
> Sorry, Cannot think of anything else.... :)
>
> I was thinking of using ADM2483 instead of MAX1480.
> DigiKey is unable to ship any Maxim or LinearTech parts
> to Singapore here (...sales boundary...) and having some
> problem with prototyping qty. ADM2483 is cheaper
> (after external DC-DC Converter included), looks very much
> like a SN75176, plus I also do not really like that MAX1480.
>
> Have not read the MAX1480 in detail. Let me do that later
> and see if I can provide you some debugging aids...
>
> ...Have fun.. and good luck... :)
> Regards
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi Unity0724 and others,
> >
> > Well, running out of things to try, it's only pulling A hi and B
> low
> > that is left to test for now. What values would you recommend?
I've
> > never had any need to so before.
> >
> > I must say that I've never had this much hard work with normal
> RS485
> > ic's from maxim. And getting the TX to work perfect but not the
RX
> is
> > very frustrating!
> >
> > It's one of the the few fully isolated RS485 circuits around so
> there
> > wasn't much to choose from! Might need to look for
alternatives...
> >
> > Back to testing...
> >
> > Cheers
> > Johan
> >
> >
> > --- In l..., "unity0724" wrote:
> > >
> > > For RS485...
> > >
> > > - Make sure you pull up A/'+' signal and Pull down B/'-'
signal
> on
> > > the RS485 bus
> > > - Make sure you use TEMT to disable your RS485 driver. Do NOT
> > > disable the RS485 driver immediately after you write the
> > > character to UART. That character will be slowly shifted
out
> > > and only completed shifting out of the UART when TEMT is set.
> > > - RS485 is half-duplex, if you do not disable the RS485
receiver
> > > when transmitting, there will be character echo-ed back to
UART
> > > receiver every time you transmit a character
> > > - For some RS485 interface parts, there might be "glitches" on
> the
> > > bus signal when you disable the RS485 driver (but this
normally
> > > get filtered off by the UART receiver)
> > >
> > > Sorry, cannot think of anything else... and Good Luck
> > > Regards
> > >
> > > BTW: I was actually happen to use that MAX1480 in the planning.
> > > Please give some info of the problem after all this... :)
> > >
> > >
> > >
> > > --- In l..., "fredrikssonjohan"
> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Some comments back on my own post.
> > > >
> > > > I have tried with blinking a led every time I'm supposed to
> > > received a
> > > > char and that LED is blinking rock solid (even if it doesn't
> say if
> > > > it's a correct received char ;-) ).
> > > >
> > > > Second, I tested against a RS-232 chip instead and it was
rock
> > > solid
> > > > echoing of the char I sent to it so I presume, once again,
> that the
> > > > actual code for receiving and sending is ok and it's
something
> with
> > > > timing or simular that makes it go wrong when using the
RS485
> chip.
> > > >
> > > > As I can send without any problem it looks like, and I have
> > > verified
> > > > the schema/pcb many times now, the connections between
LPC2106
> and
> > > the
> > > > MAXIM circuit should be fine.
> > > >
> > > > So, doing a test with interrupt handling on the comms RX
part
> > > could be
> > > > worth it. Shall have a look at the errata also.
> > > >
> > > > Someone here that have worked with the MAX1480B chip?
> > > >
> > > > Thanks for all the input and comments so far. Anything more
of
> > > ideas
> > > > or thoughts are, as before, very very welcome.
> > > >
> > > > Cheers
> > > > /Johan
> > > >
> > > > --- In l..., "fredrikssonjohan"
> wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > I'm stucked with this and can't figure out why it will not
> work.
> > > > > Anyone seeing the obvious or have any friendly ideas of
what
> > > might be
> > > > > wrong?
> > > > >
> > > > > OK. I'll try to give an as good description as possible of
> what
> > > I have
> > > > > and try do. The first problem is that if I send, as a
test,
> > > 8 "A" I
> > > > > will get 4 or 5 "A"s in return and then one or two non
ascii
> > > visible
> > > > > chars and mostly a FF as end. I would say the successrate
is
> 3-4
> > > per
> > > > > 20 sent blocks of 8 "A". So there is my problem. No clean
RX
> on
> > > the
> > > > > LPC2106 with this MAX1480B.
> > > > >
> > > > > There is a LPC2106 connected via a 74HC86 and finally the
> Maxim
> > > > > MAX1480B opto/power isolated circuit. This is all
connected
> as
> > > per
> > > > > MAXIMSs datasheet and work 100% when sending data. Never
> miss a
> > > single
> > > > > bit.
> > > > > As I never have any TX problem I figure that the init part
> of
> > > the port
> > > > > should be OK.
> > > > >
> > > > > As a stripped down testing routine I do the following:
> > > > > while (1)
> > > > > {
> > > > > cbuff[icnt] = wait_and_receive();
> > > > > icnt++;
> > > > >
> > > > > if (icnt == 8)
> > > > > {
> > > > > icnt = 0;
> > > > > IOSET = (1< > > > > > pause(TWO_MS);
> > > > > for (int j = 0; j < 8; j++)
> > > > > uart1Putch(cbuff[j]);
> > > > >
> > > > > // Back to RX mode again
> > > > > IOCLR = (1< > > > > > pause(TWO_MS);
> > > > > }
> > > > > }
> > > > >
> > > > > Im just waiting for any char in the RX buffer and switch
to
> > > RS486 TX
> > > > > mode and send it back. Added a small delay after switching
> mode
> > > on the
> > > > > RS485 line just to be sure.
> > > > >
> > > > > Using this bit just for pool until there is a char
available
> > > > > int wait_and_receive(void)
> > > > > {
> > > > > int ch;
> > > > >
> > > > > while((ch = uart1Getch()) == -1) {
> > > > > ;
> > > > > }
> > > > > return ch;
> > > > > }
> > > > >
> > > > > And this is the actual code checking if the is a char
> available.
> > > > > The uart1Getch(...) loooks like this:
> > > > > if (U1LSR & ULSR_RDR) // check if character is available
> > > > > return U1RBR; // return character
> > > > > return -1;
> > > > >
> > > > > The init is done by this and works perfect for TX
> > > > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > > > {
> > > > > // set port pins for UART1
> > > > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > > > >
> > > > > U1IER = 0x00; // disable all
> interrupts
> > > > > U1IIR; // clear interrupt
ID
> > > > > U1RBR; // clear receive
> register
> > > > > U1LSR; // clear line
status
> > > register
> > > > >
> > > > > // set the baudrate
> > > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> > > latches
> > > > > U1DLL = (uint8_t)baud; // set for baud
low
> byte
> > > > > U1DLM = (uint8_t)(baud >> 8); // set for baud
high
> byte
> > > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > > U1FCR = fmode;
> > > > > }
> > > > >
> > > > > Wow, sorry for the long message and code, but otherwise I
> guess
> > > > > someone is asking how that and that is done so I include
it
> from
> > > the
> > > > > start.
> > > > >
> > > > > If anyone have a clue or idea I would be very happy guy!
> > > > >
> > > > > Cheers
> > > > > Johan
> > > > >
> > > >
> > >
> Start a New Thread

fredrikssonjohan wrote:

> Hi All,
>
> Some comments back on my own post.
>
> I have tried with blinking a led every time I'm supposed to received a
> char and that LED is blinking rock solid (even if it doesn't say if
> it's a correct received char ;-) ).
>
> Second, I tested against a RS-232 chip instead and it was rock solid
> echoing of the char I sent to it so I presume, once again, that the
> actual code for receiving and sending is ok and it's something with
> timing or simular that makes it go wrong when using the RS485 chip.
>
> As I can send without any problem it looks like, and I have verified
> the schema/pcb many times now, the connections between LPC2106 and the
> MAXIM circuit should be fine.
>
> So, doing a test with interrupt handling on the comms RX part could be
> worth it. Shall have a look at the errata also.
>
> Someone here that have worked with the MAX1480B chip?
>
Yes, I have used that in an 8051 design. The thing to remember about
RS485 is that you are working with inductance + capacitance of the wires
interconnecting the devices. That will affect the data rate at which
you can send, the longer the distance, the lower the baudrate.
Typically, 9600 baud will only go maybe several hundred feet before
distortion occurs due to the complex filter charactoristics the wire
presents itself at. Termination of both ends of the wire with
300..600ohms does help, but it is not a cureall.

Typically all our stuff is 1200baud, nine bit data (start+9bits+stop,
essentially "stick parity").

The other thing that you have to consider when doing half duplex: when
you have both ends in RX mode, then set one side to TX, there is a
finite time interval in which you are "charging the lines". Usually
20..50ms precharge (front porch) is sufficient before you actually start
sending data out. Then, when the last bit of the last char is sent, you
have to hold the line (back porch) for about 10..15ms to allow a nice
idle interval to exist, the drop the carrier.

As to the MAX1480, I know that it can run full duplex, I've never used
it that way as a lot of the equipment I design is targeted towards
installation in older buildings. Most times you can only find a pair of
wires to use, customers hate to be told that they have to run all new
cable just so we can have full-duplex operation! Typically, you can
find that single wire pair to use.

BTW, as unbelievable as this may sound, there was one installation for a
school district in New Jersey where we discovered that the TelCo BA
lines between two points was 14miles! That data link worked solid with
no errors at 1200 baud!

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

From: "Tom Walsh"
> Yes, I have used that in an 8051 design. The thing to remember about
> RS485 is that you are working with inductance + capacitance of the wires
> interconnecting the devices. That will affect the data rate at which
> you can send, the longer the distance, the lower the baudrate.
> Typically, 9600 baud will only go maybe several hundred feet before
> distortion occurs due to the complex filter charactoristics the wire
> presents itself at. Termination of both ends of the wire with
> 300..600ohms does help, but it is not a cureall.

An RS485 is meant to be used with transmission lines: twisted pair,
terminated at BOTH ends with 100..120 Ohms (depending on the wire
characteristic impedance). A ground wire must be used to. If the receiver
cannot stand noise in the idle state biasing should be added on one position
of the cable.
If properly connected 100 kbps should be useable over 1000 meters.

See for some extra info:
http://www-s.ti.com/sc/techlit/slla070
http://tinyurl.com/hv6r2
http://www.engineerbob.com/ --> search for RS485

> BTW, as unbelievable as this may sound, there was one installation for a
> school district in New Jersey where we discovered that the TelCo BA
> lines between two points was 14miles! That data link worked solid with
> no errors at 1200 baud!

Certainly attainable if a shielded cable is used with the shield connecting
the commons of the RS485 transceivers and at least one side is galvanically
isolated. If not isolated, any lightning strike in the vicinity will
introduce enough common mode voltage to destroy drivers or receivers. The
line should be used unterminated (or with an AC termination), the DC
resistance of the wire would probably be too high to use a 120 Ohm far end
termination, and the damping of the reflected wave in 14 mile is high enough
to live without terminators anyway.

Regards,
Arie de Muijnck Start a New Thread

Hi folks,
Has anybody tried to use differential drivers for this purpose ...???
You might get better result with that.
kb
----- Original Message -----
From: Arie de Muynck
To: l...
Sent: Sunday, August 20, 2006 6:58 AM
Subject: Re: [lpc2000] Re: UART1 problem receiving but ok transmitt
From: "Tom Walsh"
> Yes, I have used that in an 8051 design. The thing to remember about
> RS485 is that you are working with inductance + capacitance of the wires
> interconnecting the devices. That will affect the data rate at which
> you can send, the longer the distance, the lower the baudrate.
> Typically, 9600 baud will only go maybe several hundred feet before
> distortion occurs due to the complex filter charactoristics the wire
> presents itself at. Termination of both ends of the wire with
> 300..600ohms does help, but it is not a cureall.

An RS485 is meant to be used with transmission lines: twisted pair,
terminated at BOTH ends with 100..120 Ohms (depending on the wire
characteristic impedance). A ground wire must be used to. If the receiver
cannot stand noise in the idle state biasing should be added on one position
of the cable.
If properly connected 100 kbps should be useable over 1000 meters.

See for some extra info:
http://www-s.ti.com/sc/techlit/slla070
http://tinyurl.com/hv6r2
http://www.engineerbob.com/ --> search for RS485

> BTW, as unbelievable as this may sound, there was one installation for a
> school district in New Jersey where we discovered that the TelCo BA
> lines between two points was 14miles! That data link worked solid with
> no errors at 1200 baud!

Certainly attainable if a shielded cable is used with the shield connecting
the commons of the RS485 transceivers and at least one side is galvanically
isolated. If not isolated, any lightning strike in the vicinity will
introduce enough common mode voltage to destroy drivers or receivers. The
line should be used unterminated (or with an AC termination), the DC
resistance of the wire would probably be too high to use a 120 Ohm far end
termination, and the damping of the reflected wave in 14 mile is high enough
to live without terminators anyway.

Regards,
Arie de Muijnck

------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006 Start a New Thread