Interbus & Profibus

W

Thread Starter

Wan Chon Kong

I need to make a comparison on the above buses, technically. What are their advantages and disadvantages?

Can anybody help me?
 
A

Andrew Piereder

It would be better if you were more specific about your application. There are a number of specifications comparisons on the internet,
but a decision on why to use one or the other depends on implications of each bus' features for the particular application.

Andy Piereder
Pinnacle IDC
 
W
Wan,

The best technical question for any network is "Will it do what you want it to do?"

It is difficult to look at tables of specifications and be able to determine this without knowing more.

Both networks use EIA-485 electrically in their most popular configuration. Interbus-S has more wires, you might include cabling cost in your
examination. Interbus-S looks like a big shift register, so updates may be faster using it (depends on number of I/O points); however, if one node goes down, any nodes downstream may not work either. This is not true of Profibus, a multidrop topology, unless the dead node's transceiver prevents any other nodes on its segment from transmitting.

Profibus has many different bit rates; Interbus-S has only one common one (500K/s). This could be a concern if the layout is large enough to make
topology at 500K a problem.

Other advantages/disadvantages may relate to what nodes you can buy off-the-shelf that do what you want. Both buses are mature enough that there are a lot of products available. I think that you can technically have more I/O points with Profibus-DP.

You can get more information at the respective websites:

http://www.interbusclub.com
http://www.profibus.com/

Caveat-my point of view is that of a product engineer. Although I have designed nodes for these and other protocols, I have no personal experience actually putting an entire system into service. Someone else will have to comment on this part.

Willy Smith
Numatico SA
Costa Rica
 
P
Hello,

Just some items out of experience:

- An Interbus module doesn't have an address that you enter on the module. It is therefore easier to
implement

- If you have to disconnect or reconnect a module
while the bus is running it is more complex to do it on Interbus S than on Profibus.

- There is no standard IP 65 connector for Profibus, while for Interbus S there is the M23 conenctor.

Regards,

Pierre Kohn
ABB Body-in-White s.a.
Beauchamp, France
 
R

Rob Hulsebos

Two persons reacted:

>1. see http://www.steinhoff.de/fb_comp.htm for an initial overview
>and links to relevant pages.

One should be very careful with such overviews, since they provide only "maxima" for all sorts of technical details, but not the interrelations between them. Without knowing more about the actual implementation of a particular network, decision to use/not use a certain network are not based on much.

Below a few comments on the steinhoff table, followed by the question that I would like you ask yourself before deciding upon a system.

- The new AS-i version 2.1 allows 62 nodes, but at the expense of allowing only three outputbits per slave.
Which network-version does your supplier deliver?

- AS-i can also have a star topology.
Which topology do you require in your application?

- AS-i can get to 300m with 2 repeaters.
Which distances must be covered in your application?

- The 375 Kbit/s for Bitbus is for a synchronous protocol. Since no startbit, stopbit and paritybit are used, there is no overhead here.
Profibus at 500 Kbit/s needs 11 bits per byte, because it must add those three extra bits. This 'raw' 500K is this equivalent to only 363K 'net'. Bitrates in themselves don't help in determining
performance, one must know more about the details.

- The 40m distance for CAN at 1 Mbit/s is only possible when you don't have galvanic isolated networktransceivers. In my opinion this is a 'must'.

Is galvanic isolation required?

- The 4-wire DeviceNet cable looks like a drawback, but note that 2 wires are used for the network, and the 2 other wires for the power-
supply for the I/O modules.
How do all the other networks power their I/O ?

Etc. etc.


>2. It is difficult to look at tables of specifications and be able to
>determine this without knowing more.

>Both networks use EIA-485 electrically in their most popular
>configuration.
>Interbus-S has more wires, you might include cabling cost in your
>examination.

That's because it is full-duplex (do the I and O simultaneously), and one of the reasons why it is so fast (see below). Profibus is half-duplex, and slower. Interbus is actually RS422 (point-to-point).

>Interbus-S looks like a big shift register, so updates may be
>faster using it (depends on number of I/O points); however, if one
>node
>goes down, any nodes downstream may not work either.

This used to be so in the past. Since a while it is possible to have subrings, and a problem there does not cause a complete breakdown, only of that subring. The main ring remains vulnerable,
however. I have seen redundantly-wired Interbus modules. I have not yet seen these for Profibus.

>This is not true of
>Profibus, a multidrop topology, unless the dead node's transceiver
>prevents any other nodes on its segment from transmitting.

Yeah, a great disadvantage of bus topologies. But you can buy repeaters to counter that (at least, if then repeater doesn't repeat the problems to the other segment. There are repeaters which have the common sense not to do this).


>Profibus has many different bit rates; Interbus-S has only one common
>one (500K/s). This could be a concern if the layout is large enough to
>make topology at 500K a problem.

Bitrate is not a useful comparison. Cycle-time is!
DP at 500K is much slower than Interbus at 500K, simply because Interbus is much more efficient. Running DP at 1.5M counters this, DP then has the same cycle-time as Interbus, just 'overkill' in
bitrate to counter all sorts of inefficiencies. So never trust salespersons that mention bitrates, they don't know what they're talking about!

Note the distances that can be covered at 500K: Profibus only a few km (with repeaters), Interbus 12km (because each busnode is itself a repeater).

Other advantages/disadvantages may relate to what nodes you can buy off-the-shelf that do what you want. Both buses are mature enough that there are a lot of products available. I think that you can
technically have more I/O points with Profibus-DP.

>You can get more information at the respective websites:

And don't forget to ask suppliers about which of the 'n' features mentioned on such websites are actually supported in their products.

Anyhow, both Interbus and Profibus have by now proven themselves. Your requirements (and $$) decide which one is the best fit.

Greetings,
Rob Hulsebos
 
A

Armin Steinhoff

Hi All,

At 17:17 23.05.00 -0400, you wrote:
>------- Forwarded message follows -------
>From: [email protected]
>To: <[email protected]-CONTROL.COM>
>Subject: Re: COMM: Interbus & Profibus
>
>Two persons reacted:
>
>>1. see http://www.steinhoff.de/fb_comp.htm for an initial overview
>>and links to relevant pages.
>
>One should be very careful with such overviews, since they provide
>only "maxima" for all sorts of technical details,

They are listed just for a raw orientation ...

>but not the interrelations between
>them. Without knowing more about the actual implementation of a
>particular network, decision to use/not use a certain network are
>not based on much.

That's the reason why we provide URLs for detailed descriptions ....

>Below a few comments on the steinhoff table, followed by the
>question that I would like you ask yourself before deciding upon a
>system.
>
>- The new AS-i version 2.1 allows 62 nodes, but at the expense of
>allow= ing only three outputbits per slave.
> Which network-version does your supplier deliver?
>
>- AS-i can also have a star topology.
> Which topology do you require in your application?
>
>- AS-i can get to 300m with 2 repeaters.
> Which distances must be covered in your application?

Detailed information are available at http://www.as-interface.com ... see the
listed ASi URL.

>- The 375 Kbit/s for Bitbus is for a synchronous protocol. Since no
>startbit, stopbit and paritybit are used, there is no overhead here.
>Profibus at 500 Kbit/s needs 11 bits per byte, because it must add
> those three extra bits. This 'raw' 500K is this equivalent to only
> 363K 'net'. Bitrates in themselves don't help in determining
>performance, one must know more about the
> details.

Nice numbers ... but not important for the end users.

>- The 40m distance for CAN at 1 Mbit/s is only possible when you
>don't have galvanic isolated networktransceivers.

Sorry, that's not correct. Galvanic isolation doesn't change any thing
because that isolation takes place between the CAN controller and the CAN
transceiver. There are no changes in the connection of the tranceiver and
the bus cable.

>In my opinion this is a 'must'.
>
> Is galvanic isolation required?
>
>- The 4-wire DeviceNet cable looks like a drawback, but note that 2
>wires are used for the network, and the 2 other wires for the power-
>supply for the I/O modules.

Confirms only the fact that DeviceNet needs a 4 wire cable ...

> How do all the other networks power their I/O ?
>
>Etc. etc.
>
>
>>2. It is difficult to look at tables of specifications and be able to
>>determine this without knowing more.
>
>>Both networks use EIA-485 electrically in their most popular
>>configuration.
>>Interbus-S has more wires, you might include cabling cost in your
>>examination.
>
>That's because it is full-duplex (do the I and O simultaneously),

Interbus isn't full duplex ...

>and one of the reasons why it is so fast (see below). Profibus is
>half-duplex, and slower.

The minimum poll cycle of Profibus is in the range of 10-20 us.
The minimum poll cycle of Interbus is in the range of 250us ...

Why should be the Interbus faster ??

> Interbus is actually RS422 (point-to-point).
>
>>Interbus-S looks like a big shift register, so updates may be
>>faster using it (depends on number of I/O points); however, if one
>>node goes down, any nodes downstream may not work either.
>
>This used to be so in the past. Since a while it is possible
>to have subrings, and a problem there does not cause a complete
>breakdown, only of that subring. The main ring remains vulnerable,
>however. I have seen redundantly-wired Interbus modules. I have not
>yet seen these for Profibus.

You should know the repeater technology of Profibus :)
Repeaters are isolating problems at the media level ...

>>This is not true of
>>Profibus, a multidrop topology, unless the dead node's transceiver
>>prevents any other nodes on its segment from transmitting.
>
>Yeah, a great disadvantage of bus topologies. But you can buy
>repeaters to counter that (at least, if then repeater doesn't
>repeat the problems to the other segment. There are repeaters
>which have the common sense not to do this).

Interesting :)

>>Profibus has many different bit rates; Interbus-S has only one common
>>one (500K/s). This could be a concern if the layout is large enough to
>>make topology at 500K a problem.
>Bitrate is not a useful comparison. Cycle-time is!
>DP at 500K is much slower than Interbus at 500K, simply because
>Interbus is much more efficient. Running DP at 1.5M counters this,
>DP then has the same cycle-time as Interbus, just 'overkill' in
>bitrate to counter all sorts of inefficiencies.

Who cares about that 'overkill' ....

>So never trust salespersons that mention bitrates, they don't know what
>they're talking about!

They know at least that Profibus at 12Mb/s is much faster than Interbus.

The event logic of the CP5613 + QNX allows indication of changes of
IO bits in the time frame of 50us .... not possible with Interbus.

>Note the distances that can be covered at 500K: Profibus only a
>few km (with repeaters)

That 'few' means also ~12km ...

>, Interbus 12km (because each busnode is itself a repeater).

[ clip ... ]

Regards

Armin Steinhoff
 
R

Rob Hulsebos

I wrote:
>- The 40m distance for CAN at 1 Mbit/s is only possible when you
>don't have galvanic isolated networktransceivers.

Armin Steinhoff replied:
>Sorry, that's not correct. Galvanic isolation doesn't change any
>thing because that isolation takes place between the CAN
>controller and the CAN transceiver. There are no changes in the
>connection of the tranceiver and the bus cable.

Well, it is not for nothing that in the last 3 years CAN publications have stopped referring to the 40m as maximum network size at 1 Mbit/s, and started using instead.

Please note that CAN is not Profibus (of which you are obviously a big fan). CAN does the arbitration of the medium while transmitting
a message, within the 11 bits of the message-ID. Each bit is continuously monitored during the transmission, to determine whether a dominant bit 'overrules' a recessive bit. This automatically means that there a strict timing-requirements, the
arbitration *must* be done during the transmission of that bit.

When a signal must travel 'through' a galvanic isolation, it is slightly delayed, and the response is slightly delayed again. For Profibus this is not of importance, but for CAN it is. And not every supplier takes the fastest (= most expensive) optocouplers!

One collegue of mine who developed a CAN-board calculated that in case you encounter all worse-case components in one system, only 10m of network length is guaranteed at 1 Mbit/s. Of course this does not happen in practice.

Greetings,
Rob Hulsebos

btw. How about porting Profibus to Ethernet directly, and skipping TCP/IP ?
 
H

Heinz-Juergen Oertel

Armin Steinhoff wrote:

> At 17:17 23.05.00 -0400, you wrote:
> >------- Forwarded message follows -------
> >From: [email protected]
> >
<clip>
> >- The 40m distance for CAN at 1 Mbit/s is only possible when you
> >don't have galvanic isolated networktransceivers.

> Sorry, that's not correct. Galvanic isolation doesn't change any
> thing because that isolation takes place between the CAN controller
> and the CAN transceiver. There are no changes in the connection
> of the tranceiver and the bus cable.

As you for sure know, CAN uses a bit arbitration along the bus. You must consider the fact, that a signal transition must go from one end to the other within the half bit time (at max). And of course a optical isolation, as most vendors do use optos as galvanic isolation, has a signal delay, depending on quality (price) of the couplers. In fact, you mostly can not reach 40m at 1 Mbit/s with opto couplers.

with best regards / mit freundlichen Gr=FC=DFen

Heinz-Juergen Oertel


Heinz-Juergen Oertel port GmbH phone +49 345 77755-0
Regensburger Str. 7c fax +49 345 77755-20 D-06132 Halle/Saale
mailto:[email protected] Germany http://www.port.de
 
A

Armin Steinhoff

>Well, it is not for nothing that in the last 3 years CAN publications
>have stopped referring to the 40m as maximum network size at 1
>Mbit/s, and started using instead.
>
>Please note that CAN is not Profibus (of which you are obviously a
>big fan). CAN does the arbitration of the medium while transmitting
>a message, within the 11 bits of the message-ID. Each bit is
>continuously monitored during the transmission, to determine
>whether a dominant bit 'overrules' a recessive bit.

This happens at tranceiver/cable level ... a transmission delay between the controller and the transceiver has no impact on the bit arbitration.

The maximum ACK delay is the limiting factor ... IMHO.

[ clip ... ]
>One collegue of mine who developed a CAN-board calculated that
>in case you encounter all worse-case components in one system,
>only 10m of network length is guaranteed at 1 Mbit/s. Of course
>this does not happen in practice.

Well ... as a 'friend of CAN' ;-) ... I would like to say that the maximum length of an 'opto isolated CAN segment' at 1Mb/s is in the range of 35 meters.

Regards

Armin Steinhoff

>btw. How about porting Profibus to Ethernet directly, and skipping
>TCP/= IP ?

Wow ... would be the rebirth of MAP :) Why not ....
 
R

Robert Lunnon

Just a few comments (Belated I know)

> -----Original Message-----
> From: Armin Steinhoff [mailto:[email protected]]
>
> At 16:34 25.05.00 -0400, you wrote:
> >------- Forwarded message follows -------
> >From: [email protected]
> >I wrote:
> >>- The 40m distance for CAN at 1 Mbit/s is only possible when you
> >>don't have galvanic isolated networktransceivers.

This is correct

> >Armin Steinhoff replied:
> >>Sorry, that's not correct. Galvanic isolation doesn't change any
> >>thing because that isolation takes place between the CAN
> >>controller and the CAN transceiver. There are no changes in the
> >>connection of the tranceiver and the bus cable.

Yes it does, the 40 m limitation results from the fact that the start of the bit period for the inserted acknowledge is framed by the sender of the message. The inserted acknowledge bit will be delayed by twice the propagation delay from the sender to the receiver. If the propagation delay
is too long then the acknowlege bit is incorrectly sampled by the sending node and the protocol falls over. ABSOLUTLEY ANYTHING affecting propagation delay then impacts on the maximum cable length. This includes the velocity
factor of the cable, the drivers and receivers used, any opto-isolation used. (Maybe the orientation of the cable, everyone knows electrons flow faster downhill :)

> >Well, it is not for nothing that in the last 3 years CAN publications
> >have stopped referring to the 40m as maximum network size at 1
> >Mbit/s, and started using instead.
> >
> >Please note that CAN is not Profibus (of which you are obviously a
> >big fan). CAN does the arbitration of the medium while transmitting
> >a message, within the 11 bits of the message-ID. Each bit is
> >continuously monitored during the transmission, to determine
> >whether a dominant bit 'overrules' a recessive bit.
>
> This happens at tranceiver/cable level ... a transmission
> delay between
> the controller
> and the transceiver has no impact on the bit arbitration.
>
> The maximum ACK delay is the limiting factor ... IMHO.

That's right as I understand it the ACK delay is the worst case but don't forget that if you consider two nodes, x metres apart and trying to transmit at the same time will fail to arbitrate correctly if the propagation delay between them exceeds 1/2 bit period ! The ACK delay is also definately affected by the propagation delay of the media (and intermediate opto-couplers).


> [ clip ... ]
> >One collegue of mine who developed a CAN-board calculated that
> >in case you encounter all worse-case components in one system,
> >only 10m of network length is guaranteed at 1 Mbit/s. Of course
> >this does not happen in practice.
>
> Well ... as a 'friend of CAN' ;-) ... I would like to say
> that the maximum
> length
> of an 'opto isolated CAN segment' at 1Mb/s is in the range of
> 35 meters.
>

That'd probably be about right

Just generally for the originator of this thread I'd like to make some comments. Firstly, determine what you need. Which fieldbus is best for you depends a lot on what you are trying to get out of it. Try to determine a transaction rate for your application since this is a more sensible parameter to design with. Data rate doesn't help much. For example most lay people consider ethernet pretty fast. But after layering TCP/IP in each ethernet packet you have 2 56 bit ethernet identifiers plus two 32 bit IP
addresses and a 16 bit port address as well as at least 16 bit of protocol identification. This creates an overhead of at least 208 bits per message without the HDLC framing overheads as well. If you are sending a single byte data package to a fieldbus device the total packet is at least 216 bits and takes at least 21.6 uS at 10 Mb/s. Profibus for the same packet has about 32
bits of overhead giving a total packet of about 50 bits (Including parity) at 12 Mb/s the transaction time is 5uS at the same bit rate making Profibus much more efficient (Actual implementations over TCP/IP are probably much
worse than this). CAN is more efficient again with CAN 2 requiring only 22 bits of overhead. (Remembering of course that any higher layer may add error control overhead to this).


Anyway this is how I do the comparison:
First you need to determine your average data block size and the number of stations to determine your transaction rate. This is often difficult because the transaction rate information is not always given by the vendors. This then can indicate the maximum tolerable cycle time of your system. Once you have decided which fieldbusses and bit rates can provide you with the cycle times (Transaction rate) you require, you can then decide between them on
other factors. The other factors are, in order of evaluation (IMHO):

Required geometry... Canbus variants (Devicenet, CanOpen etc) use a bit arbitration method that is affected by propagation delays, if the maximum
cable length of your application exceeds that allowed at the bitrate you need to meet your transaction rate you can elliminate that contender. By the way, some proponents of interbus cite the long legths of network it
supports. This is not strictly true, the maximum length of an interbus is dictated by the maximum cable length between each node by the number of
allowable nodes. This is fine in theory but in practise it is more likely that your geometry will be dictated by where the equipment to be
monitored/controlled is actually located ;-) The maximum segment length is a more appropriate guide.

Reliability.. This includes the ability to support hot changes or redundant signalling modes, the amount of error control in the protocol or other environmental factors all figure in this assessment. Interbus commonly fails
this test due to a lower level of error control and the need to break the ring to remove or insert nodes (although there are ways around this)

Features... This can factor a bit, for example some fieldbusses provide the ability to broadcast allowing sample and hold and synchronising facilities. If you need all the I/O on your system to be sampled or to change
simultaneously this is an essential feature for you. Peer to peer signalling might be another.

Cost, Always a biggie :)

Availability... Can you source the components easilly and are alternative sources (Vendors) or devices available.

Hope this helps

Robert
 
A

Armin Steinhoff

At 06:07 07.06.00, "Lunnon, Robert" <[email protected]> wrote:
>Just a few comments (Belated I know)
>
> > -----Original Message-----
> > From: Armin Steinhoff [mailto:[email protected]]
> > Sent: Saturday, 27 May 2000 0:08

[ clip ...]

>Yes it does, the 40 m limitation results from the fact that the start of the
>bit period for the inserted acknowledge is framed by the sender of the
>message. The inserted acknowledge bit will be delayed by twice the
>propagation delay from the sender to the receiver. If the propagation delay
>is too long then the acknowlege bit is incorrectly sampled by the sending
>node and the protocol falls over.

OK ... my statement was: not the (failing?) bit arbitration is the reason for the limitation of the segment length ... it is the ACK delay. The ACK bit (set by the receiver) must be sampled in a 2 bit window by the sender ... that means it has to pass the opto coupler.

[ clip .. ]

> > The maximum ACK delay is the limiting factor ... IMHO.
>
>That's right as I understand it the ACK delay is the worst case but dont
>forget that if you consider two nodes, x metres apart and trying to transmit
>at the same time will fail to arbitrate correctly if the propagation delay
>between them exceeds 1/2 bit period !

Sorry ... the bit arbitration depends on the propagation delay on the cable. The propagation delay between the controler and transceiver has no effect for the _bit arbitration_.

Best Regards

Armin Steinhoff
 
R

Rob Hulsebos Philips CFT

>Data rate doesn't help much. For example most lay
>people consider ethernet pretty fast. But after layering TCP/IP in each
>ethernet packet you have 2 56 bit ethernet identifiers plus two 32 bit IP
>addresses and a 16 bit port address as well as at least 16 bit of protocol
>identification. This creates an overhead of at least 208 bits per message

Don't forget the minimum length is 512 bits.
TCP/IP headers fit well in this, so no additional overhead is incurred.

>Profibus for the same packet has about 32
>bits of overhead giving a total packet of about 50 bits (Including parity)at

That is not correct. The minimum frame for two bytes of data has a start-delimiter, destination-address, source-address. frame control byte,
checksum, and an end-delimiter byte, adding 6 bytes of overhead. Add to this the 33 bits silence at the beginning, the 2 bytes of user data, and a minimum acknowledgement by the receiver of 1 byte, and then you end up at 33+(6+2)*11+1*11=132 bits. 11 bits per byte because of startbit, 8 databits, paritybit, stopbit. And I haven't yet included the slave delay in the calculations.

>CAN is more efficient again with CAN 2 requiring only 22
>bits of overhead. (Remembering of course that any higher layer may add error
>control overhead to this).

Aren't there 47 bits of overhead here, and perhaps the additional stuff-bits (depending on the contents of the frame).

Greetings,
Rob Hulsebos
 
H

Heinz-Juergen Oertel

Rob Hulsebos Philips CFT wrote:
>
[snip]
> >CAN is more efficient again with CAN 2 requiring only 22
> >bits of overhead. (Remembering of course that any higher layer may add error
> >control overhead to this).
>
> Aren't there 47 bits of overhead here, and perhaps the
> additional stuff-bits (depending on the contents of the frame).
>

To complicate it even more:
you can use some of the arbitration bits (identifier) as message information and use, for example, only the highest 4 bit for message addressing. This reduces the overhead to 47-(11+4) = 40 bit (without stuffing, ok) and increases the message length to 64+(11-4) = 71 bit

(based on the 11 bit id format)

--
with best regards / mit freundlichen Grüßen

Heinz-Jürgen Oertel

===========================================
Heinz-Jürgen Oertel
port GmbH phone +49 345 77755-0
Regensburger Str. 7c fax +49 345 77755-20
D-06132 Halle/Saale mailto:[email protected]
Germany http://www.port.de
===========================================
 
R

Ralph Mackiewicz

> Try to determine a transaction rate for your application since this
> is a more sensible parameter to design with. Data rate doesn't help
> much. For example most lay people consider ethernet pretty fast.
> But after layering TCP/IP in each ethernet packet you have 2 56 bit
> ethernet identifiers plus two 32 bit IP addresses and a 16 bit port
> address as well as at least 16 bit of protocol identification. This
> creates an overhead of at least 208 bits per message without the
> HDLC framing overheads as well. If you are sending a single byte
> data package to a fieldbus device the total packet is at least 216
> bits and takes at least 21.6 uS at 10 Mb/s. Profibus for the same
> packet has about 32 bits of overhead giving a total packet of about
> 50 bits (Including parity)at 12 Mb/s the transaction time is 5uS at
> the same bit rate making Profibus much more efficient (Actual
> implementations over TCP/IP are probably much worse than this).

Focusing only on performance is not the answer. There are numerous functional characteristics of a fieldbus that are more important in determining its suitability for a given application.

Besides, performance cannot be evaluated by looking at transaction rates and protocol overheads. A detailed understanding of the entire
protocol stack, its functions, and its limitations are needed in order to get a clear picture of performance in a given situation.
While Profibus has a lower bit overhead than TCP/IP Ethernet, I can transmit hundreds to thousands of data points in a single application
transaction using MMS-TCP/IP-Ethernet where Profibus would take many many more transactions due to its limited frame size (240 bytes of user data I think it is). The result would be much better performance even though there are many more overhead bytes on the wire.

Regards,
Ralph Mackiewicz
SISCO, Inc.

The opinions given above should be attributed to me and not my company because my company did not write them...I did.
 
R
>>[discussing efficiency of CAN...]
>> Aren't there 47 bits of overhead here, and perhaps the
>> additional stuff-bits (depending on the contents of the frame).
>
>to complicate it even more:
>you can use some of the arbitration bits (identifier)
>as message information and use, for example, only the highest 4 bit
>for message addressing.
>This reduces the overhead to 47-(11+4) = 40 bit (without stuffing, ok)
>and increases the message length to 64+(11-4) = 71 bit

Even more efficiency-gain is possible. With some of the older CAN controllers one could use data-length codes with values >= 9, this gives you 8 possibilities to send messages of 8 bytes, so another 3 bits extra for data gained. And then I haven't thought about clever use of the RTR-bit....

Groeten,
Rob Hulsebos
 
Top