Serial Bus Choices

[Joel]

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

We have some constraints on size, weight and shape because we will need
to fit into leftover space inside unspecified packages. This makes me
tend away from COTS plug-in-board solutions, which would make ethernet,
USB, or 1553 simple to implement.

Our controllers for these modules will likely be from the AVR family -
this is not set in stone but we already have experience with them and
the tools. We don't expect to have huge amounts of data on this bus
(it's mostly for command and status to a few sensors and motor
controllers) and we don't currently know how many nodes we will need.
The reason for having separate modules at all is to make it easier to
adjust for feature creep and add new functionality without respinning
every board when this happens.

I know there are some holes in this info and I will answer any
questions that I can.

Thanks,

 

[Joel Kolstad]

Joel,

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

I like your reasoning. Here's my thoughts on the other options:

Ethernet, FireWire: Adds considerable complexity & power consumption
USB: Not really a "networking" protocol; requires a single master and many
slaves, so not directly applicable to systems with many boards that are
"peers"
1553, CAN-BUS: I don't know enough about these to comment, although it would
appear that at least with CAN-BUS you'd need an extra controller IC since I
don't believe it can be bit-banged?

You might want to look at I2C which would probably also meet your needs and
perhaps obviate the need for RS-485 line drivers/receivers, but otherwise --
given your low data-rate and the need to keep an eye on power consumption -- I
think RS-485 is a very solid choice. About the only downside I can think of
it that you'll end up having to come up with your own protocol (not at all
difficult), whereas something like Ethernet/FireWire/USB already have the
lowest-level "frame" packets defined.

 

[Joerg]

Hello Joel,

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

I happen to work on something similar right now and I am looking into a
similar bus architecture. But I'll exceed the usual 32 receiver limit
just by a smidgen :-(

If this is for a defense project you might want to think about these
reasons for adopting a simple serial bus:

+ Has been around for a very long time (IOW, it works).
+ Look at RS232: Often dissed but still around, for decades.
+ Lots of people are familiar with it.
+ Simplicity, meaning less can go wrong.
+ Possibly less reliance on single-source parts.
+ Not much overhead.
+ Can be diagnosed with just about any old scope or analyzer.
+ Lots of simple and cheap terminal software.
+ Probably lots of other defense gear that has it.

We have some constraints on size, weight and shape because we will need
to fit into leftover space inside unspecified packages. This makes me
tend away from COTS plug-in-board solutions, which would make ethernet,
USB, or 1553 simple to implement.

Plug-in boards on anything that goes airborne, or anything else for that
matter, reduce the reliability because you have more connectors.

Our controllers for these modules will likely be from the AVR family -
this is not set in stone but we already have experience with them and
the tools. We don't expect to have huge amounts of data on this bus
(it's mostly for command and status to a few sensors and motor
controllers) and we don't currently know how many nodes we will need.
The reason for having separate modules at all is to make it easier to
adjust for feature creep and add new functionality without respinning
every board when this happens.

Using something that you are already familiar with is a smart thing to do.

 

[J.A. Legris]

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

We have some constraints on size, weight and shape because we will need
to fit into leftover space inside unspecified packages. This makes me
tend away from COTS plug-in-board solutions, which would make ethernet,
USB, or 1553 simple to implement.

Our controllers for these modules will likely be from the AVR family -
this is not set in stone but we already have experience with them and
the tools. We don't expect to have huge amounts of data on this bus
(it's mostly for command and status to a few sensors and motor
controllers) and we don't currently know how many nodes we will need.
The reason for having separate modules at all is to make it easier to
adjust for feature creep and add new functionality without respinning
every board when this happens.

I know there are some holes in this info and I will answer any
questions that I can.

Thanks,

I would recommend CAN or one of its subsets such as J1939. It's
everywhere now and you won't have to worry about convincing your
customer.

http://www.atmel.com/dyn/products/product_card.asp?part_id=3388

 

[Joel]

Joel,



I like your reasoning. Here's my thoughts on the other options:

Ethernet, FireWire: Adds considerable complexity & power consumption
USB: Not really a "networking" protocol; requires a single master and many
slaves, so not directly applicable to systems with many boards that are
"peers"

I generally agree with this as well, except for the USB, because we
were already considering that one module would be a master for the
system. My problem with USB is the expectation that you could just
plug it into a port on a PC. My understanding is that there would be
considerable firmware overhead to do this.

1553, CAN-BUS: I don't know enough about these to comment, although it would
appear that at least with CAN-BUS you'd need an extra controller IC since I
don't believe it can be bit-banged?

CAN does require a seperate controller, but you get some failsafing
along with it.

You might want to look at I2C which would probably also meet your needs and
perhaps obviate the need for RS-485 line drivers/receivers, but otherwise --
given your low data-rate and the need to keep an eye on power consumption -- I
think RS-485 is a very solid choice. About the only downside I can think of
it that you'll end up having to come up with your own protocol (not at all
difficult), whereas something like Ethernet/FireWire/USB already have the
lowest-level "frame" packets defined.

We like the fact that we would develop our own protocol. Many of the
other choices enforce a particular protocol that would waste a lot of
bandwidth to send 1 byte of status.

Joel

 

[Joel]

Hello Joel,



I happen to work on something similar right now and I am looking into a
similar bus architecture. But I'll exceed the usual 32 receiver limit
just by a smidgen :-(

With the newer 485 transceivers you can have upto 256 nodes. CAN does
not use addressing, so you can have lots of nodes so long as you
terminate proporly.

If this is for a defense project you might want to think about these
reasons for adopting a simple serial bus:

+ Has been around for a very long time (IOW, it works).
+ Look at RS232: Often dissed but still around, for decades.
+ Lots of people are familiar with it.
+ Simplicity, meaning less can go wrong.
+ Possibly less reliance on single-source parts.
+ Not much overhead.
+ Can be diagnosed with just about any old scope or analyzer.
+ Lots of simple and cheap terminal software.
+ Probably lots of other defense gear that has it.

We have some problems with 232:
Single ended means less noise immunity compared to differential
Point-to-point limits the number of modules to the number of uarts
on the main module
1 Mb/s might eventually be too low a bandwidth (485 can go to 50
Mb/s over short runs)

Plug-in boards on anything that goes airborne, or anything else for that
matter, reduce the reliability because you have more connectors.

I agree with this but 1553 boards are in most subsystems on most
military aircraft. My problem with 1553 is the complexity to implement
in an embedded system.

 

[Joel]

I would recommend CAN or one of its subsets such as J1939. It's
everywhere now and you won't have to worry about convincing your
customer.

http://www.atmel.com/dyn/products/product_card.asp?part_id=3388

I think that CAN is my second choice. My main problem with it is 8
bytes of data per packet.

 

[PeteS]

I would recommend CAN or one of its subsets such as J1939. It's
everywhere now and you won't have to worry about convincing your
customer.

http://www.atmel.com/dyn/products/product_card.asp?part_id=3388

I use CAN with J1939 as transport in one product, and it has some
advantages (it's designed to be bulletproof), and lots of parts available.

To implement properly, you'll need a CAN controller either standalone or
as part of a microcontroller, and a CAN transceiver - lots of these
available from the usual suspects.

The issue is it may be overkill, and it has limited bandwidth. 1Mb/s
over relatively short runs, which from a different post may not be suitable.

As to the original post; my take is to use the simplest possible
interconnect that will meet the task. In this case, RS485 seems to be an
excellent choice.

Keep in mind that all the others (be it CAN, ethernet, firewire, USB,
whatever) will have *significant* software/firmware overhead. That adds
a complexity layer that is actually worse than the hardware
complexities. No - keep it simple.

Cheers

PeteS

 

[Joel]

I use CAN with J1939 as transport in one product, and it has some
advantages (it's designed to be bulletproof), and lots of parts available.

To implement properly, you'll need a CAN controller either standalone or
as part of a microcontroller, and a CAN transceiver - lots of these
available from the usual suspects.

The issue is it may be overkill, and it has limited bandwidth. 1Mb/s
over relatively short runs, which from a different post may not be suitable.

As to the original post; my take is to use the simplest possible
interconnect that will meet the task. In this case, RS485 seems to be an
excellent choice.

Keep in mind that all the others (be it CAN, ethernet, firewire, USB,
whatever) will have *significant* software/firmware overhead. That adds
a complexity layer that is actually worse than the hardware
complexities. No - keep it simple.

Cheers

PeteS

I agree with everything you said. My customer is used to buying COTS
boards for whatever function he needs. I don't think he understands
how much more difficult it is to implement some of these things in an
embedded system. Although, maybe this is just a test to see if I can
really justify my choice.8)

 

[Joel]

I use CAN with J1939 as transport in one product, and it has some
advantages (it's designed to be bulletproof), and lots of parts available.

To implement properly, you'll need a CAN controller either standalone or
as part of a microcontroller, and a CAN transceiver - lots of these
available from the usual suspects.

The issue is it may be overkill, and it has limited bandwidth. 1Mb/s
over relatively short runs, which from a different post may not be suitable.

As to the original post; my take is to use the simplest possible
interconnect that will meet the task. In this case, RS485 seems to be an
excellent choice.

Keep in mind that all the others (be it CAN, ethernet, firewire, USB,
whatever) will have *significant* software/firmware overhead. That adds
a complexity layer that is actually worse than the hardware
complexities. No - keep it simple.

Cheers

PeteS

I agree with everything you said. My customer is used to buying COTS
boards for whatever function he needs. I don't think he understands
how much more difficult it is to implement some of these things in an
embedded system. Although, maybe this is just a test to see if I can
really justify my choice.8)

 

[Joel]

I use CAN with J1939 as transport in one product, and it has some
advantages (it's designed to be bulletproof), and lots of parts available.

To implement properly, you'll need a CAN controller either standalone or
as part of a microcontroller, and a CAN transceiver - lots of these
available from the usual suspects.

The issue is it may be overkill, and it has limited bandwidth. 1Mb/s
over relatively short runs, which from a different post may not be suitable.

As to the original post; my take is to use the simplest possible
interconnect that will meet the task. In this case, RS485 seems to be an
excellent choice.

Keep in mind that all the others (be it CAN, ethernet, firewire, USB,
whatever) will have *significant* software/firmware overhead. That adds
a complexity layer that is actually worse than the hardware
complexities. No - keep it simple.

Cheers

PeteS

I agree with everything you said. My customer is used to buying COTS
boards for whatever function he needs. I don't think he understands
how much more difficult it is to implement some of these things in an
embedded system. Although, maybe this is just a test to see if I can
really justify my choice.8)

 

[Adrian Jansen]

I think that CAN is my second choice. My main problem with it is 8
bytes of data per packet.

I use RS485 in a similar situation, with SNAP protocol. But even with a
very simple protocol, by the time you do addressing and error detection,
you will end up with around 8 byte packets to do anything useful.


--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

 

[Joel]

Damn Google Groups. This was obviously only supposed to go out once.

 

[PeteS]

Damn Google Groups. This was obviously only supposed to go out once.

LOL

That happened to me when I posted from my cousin's computer using google
groups last week.

No problem

Cheers

PeteS

 

[John Larkin]

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

We have some constraints on size, weight and shape because we will need
to fit into leftover space inside unspecified packages. This makes me
tend away from COTS plug-in-board solutions, which would make ethernet,
USB, or 1553 simple to implement.

Our controllers for these modules will likely be from the AVR family -
this is not set in stone but we already have experience with them and
the tools. We don't expect to have huge amounts of data on this bus
(it's mostly for command and status to a few sensors and motor
controllers) and we don't currently know how many nodes we will need.
The reason for having separate modules at all is to make it easier to
adjust for feature creep and add new functionality without respinning
every board when this happens.

I know there are some holes in this info and I will answer any
questions that I can.

Thanks,

We just had a meeting at which we re-affirmed the truism that the
easiest protocol to implement is one that you design yourself.

I'd go for RS-485 with a simple, home-brew binary packet protocol. A
single tri-statable RS485 transceiver chip will be an SO-8 at most,
hardly any space or power, and your CPU probably has a suitable UART
on-board.

John

 

[Rene Tschaggelar]

I use RS485 in a similar situation, with SNAP protocol. But even with a
very simple protocol, by the time you do addressing and error detection,
you will end up with around 8 byte packets to do anything useful.

8 bytes to start with, not maximum

Rene

 

[The Real Andy]

My company is designing the electronics for some UAV payloads and we
are trying to decide on an inter-module serial comm scheme.
Internally, we had chosen 485, but our customer asked why 485 and not
ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
them and would like some input from this group.

We have some constraints on size, weight and shape because we will need
to fit into leftover space inside unspecified packages. This makes me
tend away from COTS plug-in-board solutions, which would make ethernet,
USB, or 1553 simple to implement.

Our controllers for these modules will likely be from the AVR family -
this is not set in stone but we already have experience with them and
the tools. We don't expect to have huge amounts of data on this bus
(it's mostly for command and status to a few sensors and motor
controllers) and we don't currently know how many nodes we will need.
The reason for having separate modules at all is to make it easier to
adjust for feature creep and add new functionality without respinning
every board when this happens.

I know there are some holes in this info and I will answer any
questions that I can.

Thanks,

Nice replies from all. But when you go to your customer and say, RS485
(or alternate solution) is the best value for money when it comes to
cost v reliablility i think your customer will be happy. Weigh up the
cost, then make a decision.

Tell them CAN will cost more, but is more robust or ethernet requires
more hardware (and subsequently $$) but is more scaleable etc. Do
yourself a favour and write down approximate costs of each solution
and next to that write down pro's v con's. Take several options to
your customer and let them choose which way they want to go based on
your educated opinion.

Someone is paying you, give them what they want and you will get more
work.

 

[Joel]

We just had a meeting at which we re-affirmed the truism that the
easiest protocol to implement is one that you design yourself.

This was our thoughts as well.

I'd go for RS-485 with a simple, home-brew binary packet protocol. A
single tri-statable RS485 transceiver chip will be an SO-8 at most,
hardly any space or power, and your CPU probably has a suitable UART
on-board.

John

I definitely agree with all of this. We have done a couple of projects
recently where we rolled our own protocol, and it worked fine.

 

[Joel]

Nice replies from all. But when you go to your customer and say, RS485
(or alternate solution) is the best value for money when it comes to
cost v reliablility i think your customer will be happy. Weigh up the
cost, then make a decision.

I still think that this was something of a test, to see how much
thought we had put into the decision.

Tell them CAN will cost more, but is more robust or ethernet requires
more hardware (and subsequently $$) but is more scaleable etc. Do
yourself a favour and write down approximate costs of each solution
and next to that write down pro's v con's. Take several options to
your customer and let them choose which way they want to go based on
your educated opinion.

I am keeping a spreadsheet with as many comparative metrics on each
protocol as I can find. I plan on coming up with a weighting scheme
for each metric and willhave a relative merit value for each at the
end.

 

[John B]

We just had a meeting at which we re-affirmed the truism that the
easiest protocol to implement is one that you design yourself.

I'd go for RS-485 with a simple, home-brew binary packet protocol. A
single tri-statable RS485 transceiver chip will be an SO-8 at most,
hardly any space or power, and your CPU probably has a suitable UART
on-board.

John

Having designed many industrial machines with internal RS485 networks,
I agree with all that has gone before with one minor exception. I would
suggest that you design your protocol in readable ASCII. That way you
can make a debugging tool with a laptop running
TeraTerm/HyperTerminal/Whatever and an RS485->RS232 converter.

If you are sure your system will always have one fixed master, then
also look at four-wire RS422. That way there is no possibility of
running into bus contention problems.