UART Cable Advice

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all.

I need some hardware advice. In my application my controller will have to be 18 inches (46 cm) away from 6 analog sensors, a motor, a quadrature encoder, and one unipolar hall effect sensor. I am concerned about niose if I run the analog signals along 18 inches of wire right next to the PWM controlled motor wires and the quadrature encoder wires. Plus it is desirable to reduce the number of wires because this particular cable has to flex repeatedly.

My first thought is to connect the six analog sensors to a second MCU and send the data over the uart to the primary controller. However if I do this I would need to send a bare minimum of 12 bytes every 1 ms. In order to reduce latency I would want a baud rate of about 250 kbit/s. Ive never had an application with this high of data rate.

Is it practical to communicate at 250 kbit/s over 18 inch (46 cm) of cable length with a 3.3V UART? Do I need special cable/connectors?

Any comments/insight are greatly appreciated.

-Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like(love?) to use differential transceivers in situations like this. 250kbps at that distance is definitely practical.

Here's an example part http://www.sparkfun.com/datasheets/Components/General/sp3485CN-LTR.pdf

I have too many hobbies.
s-conductor.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Optical (TOSLINK) is not an option?

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pick an RS485 transceiver that is fast enough, but not far more than that. You can get 250kbps types that have slew rate control on the transmitters, and filtering on the receivers. They are not more expensive than the fast, unfiltered versions.

At 76.8 kbps you can do many, many nodes on 1.5km of wire. I have tested 230k on 500m cable, and it is perfectly good on the other end.

A cable that you can run 3.3V CMOS single ended though right next to motor wires and will survive in a robotic application is likely to exceed the cost of the transceivers. Igus has some, but they are not cheap. Good yes, but not cheap.

/Kasper

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

KKP wrote:
Pick an RS485 transceiver that is fast enough, but not far more than that. You can get 250kbps types that have slew rate control on the transmitters, and filtering on the receivers. They are not more expensive than the fast, unfiltered versions.

At 76.8 kbps you can do many, many nodes on 1.5km of wire. I have tested 230k on 500m cable, and it is perfectly good on the other end.

A cable that you can run 3.3V CMOS single ended though right next to motor wires and will survive in a robotic application is likely to exceed the cost of the transceivers. Igus has some, but they are not cheap. Good yes, but not cheap.

/Kasper

I read up on RS-485 and I think it will work fabulously.

mhatter: Thanks for the IC suggestion. That one looks like it would work well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think at 250 Kbits your limiting factor might be your baud rate generator accuracy rather then the short distance transmission line.
My thought are that a shielded cable 18" long should work fine at 250Kbits and you should try it before you go to other extremes.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, so I'm not a motors kind'a guy, but I've gotta ask:

So what is the frequency response of the system? Updates every mSec would seem to be a pretty fast loop time for many mechanical systems.

You could also look at data compression to decrease the number of bits you need to send with each packet, and also see if it is feasible to put more of the controller electronics at the source of the signal generation, instead of "remotely", note that 18" is not all that "remote"...

What redundancy is built in to the data transmission? Checksum? CRC? None? What happens to the system if a bad packet is received?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
OK, so I'm not a motors kind'a guy, but I've gotta ask:

So what is the frequency response of the system? Updates every mSec would seem to be a pretty fast loop time for many mechanical systems.

The motor I am using can accelerate from stopped to full speed in about 8ms.

DocJC wrote:
You could also look at data compression to decrease the number of bits you need to send with each packet, and also see if it is feasible to put more of the controller electronics at the source of the signal generation, instead of "remotely", note that 18" is not all that "remote"...
I will definitely give some thought to compression.

I would love to put all the components with the sensors but I am super tight on space.

DocJC wrote:
What redundancy is built in to the data transmission? Checksum? CRC? None? What happens to the system if a bad packet is received?

JC

I have not yet decided what redudundancy I will use but I will definitely have something. I know that the my ATMEGA324p has built in parody system. I might look into that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LDEVRIES wrote:
I think at 250 Kbits your limiting factor might be your baud rate generator accuracy rather then the short distance transmission line.
My thought are that a shielded cable 18" long should work fine at 250Kbits and you should try it before you go to other extremes.
Do you think buad rate accuraccy will be an issue for two ATMEGA324p's running off two 12Mhz XTALs? I wouldn't think so because my XTALs are ± 50ppm @ 25°C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Do you think buad rate accuraccy will be an issue for two ATMEGA324p's running off two 12Mhz XTALs? I wouldn't think so because my XTALs are ± 50ppm @ 25°C.
It's not important the two 324's are running the same crystals. What is important is the baud rate you're trying to achieve given the speed your clock is.

In the 324 datasheet in section 16.12 it shows how to determine the error (and what error is typically acceptable).

12MHz and 250kbps should be 0.0% error.

I have too many hobbies.
s-conductor.com