error detection rate with crc-16 CCITT

make

ts

of

I'm not following. If a message is corrupted but still looks like a valid message then the corrupted message will still get removed from the ring after it's been around once because each node will find in its list of "recent" messages.

Each message placed on the ring is duplicated so that one copy goes CW and one goes CCW until they meet up. Both copies would have to be lost/ damaged for the message not to get right around. Critical data is actually refreshed in this system.

Do you mean that the message gets ackd but it was actually damaged? The other copy of the message would have to get damaged too.

I'm not sure where I said 19 out of 60 - it was something to do with the Reed Solomon thing I think. I think I was trying to find out how many bytes of overhead there would be for significantly better error detection, however the CPU overhead is too great.

A fellow engineer had speculated that we could live with 10% errors at the faster baud rate. My recommendation is now going to be that we have to see no increase in errors (i.e. more or less no errors) to stay at the faster rate - if we do this at all. It's been suggested that the nature of the errors due to running too fast on un-twisted non-shielded cable will make it immediately obvious that we're going too fast. We'll also add some 55 and AA bytes to the "idle" packets exchanged between nodes to help detect errors. I guess if real noise occurs and we're running at the faster rate, we won't know whether to drop back to the slower rate or not.

Yes.

No. The request/ response we need to speed up has perhaps 30 bytes out-going and 200 bytes returned. I estimated 10 milliseconds per node for the out-going message and 40 ms for the return message. 32 times 10 plus 32 times 40 is approx 1.6 seconds plus some extra processing time at each end. My estimate is probably a little bit low.

Yep, we looked at full duplex but we need to allow 2 wire connections. We're also considering splitting the longer messages into shorter ones.

With the ring, the system still operates when there is a break or short somewhere. With multidrop and 2 wires, a short takes down the whole bus so we have 4 wires between devices with each pair supposed to be routed on a different path. The signal is duplicated on both pairs of wire, except for when we're checking the integrity of each pair individually.

le

Hmm, ok, if the byte count goes wrong as well I guess it could - I didn't think of that. The ddcmp protocol actually has a 10 byte header (can't remember if I mentioned this) with a separate crc for the header. The count byte for the data is in the header. I suspect the chance of it morphing into something valid would be pretty low in our case - e.g. one particular byte must always have the value 0x01.

So the detection of 1,2 and 3 bit errors by crc16-ccitt doesn't allow for start bit and stop bit errors? I never thought of that either.

To get faster request/ response - a shorter propagation delay.

ll

This is true for each uart.

I don't follow this. It's not a bus. 18 and 19 can talk to each other and no-one else hears.

I have a feeling there's a misunderstanding here - not sure what though.

Yes, they do.

ok - it actually dies at around about the 2&2 , 3&1 stage

No, the baud rate between any two nodes is independent of any other two nodes. I'm missing something here.

=A0 =A0 =A0 =A0 =A0 CCCC

=A0 =A0 =A0 =A0 =A0 CCCC

Off the top of your head, do you have any idea what the execution time to do huffman compression of 200 bytes of text would be on the 32C87?

We did profile the code at one stage, using a scope on a port line that was triggered on entry and exit from the function, but don't have the results to hand, only that it was fast enough...

Regards,

Chris

As message size goes up (transmission time increases), you have all the more incentive to passing the message along before it is completely received. If, e.g., you can reduce the effective "hold-over" time at each node to 10 bytes (from 200), then you can trim 30ms from that

I'm confused. Why do you think "full duplex" and "2 wire" are contradictions?

I am not telling you to add or change any wiring/hardware. Each node has two inputs (one for the CW ring and another for the CCW ring) and two outputs (ditto).

What I am saying is that you start propagating an incoming packet

So, instead of (effectively): count = 0 do { buffer[count++] = get_byte() } while (count < MESSAGE_SIZE)

// have now gobbled up entire incoming message!

if (message_is_for_me(buffer)) { process_mesage(buffer, MESSAGE_SIZE) } else { // not for me so pass the whole message on... transmit_message(buffer, MESSAGE_SIZE) }

do something like: count = 0 do { buffer[count++] = get_byte() } while (count < HEADER_SIZE)

// now have JUST the header/routing portion of the message

if (message_is_for_me(buffer)) { // gather up the rest of this message as it belongs to me! do { buffer[count++] = get_byte() } while (count < MESSAGE_SIZE) // have now gobbled up entire incoming message so deal with it! process_message(buffer, MESSAGE_SIZE) } else { // not intended for me so pass what I have, so far, along transmit_message(buffer, HEADER_SIZE) do { // and, pass along each subsequent byte as it is received transmit(get_byte()) } while (++count < MESSAGE_SIZE) }

You are running Tx and Rx at the same time but not really in the traditional application of "full duplex". You overlap transmission (propagation) of the message with it's reception.

With a SINGLE RING, you can't make that claim -- since there is no way to get messages "across" the break. I.e., if there is a break between nodes 3 & 4, then 1 can talk to 2 and 2 can talk to 3 -- but 3 can't talk to 4 *and* 2 can't REPLY to 1 nor can 3 reply to 2 (or 1), etc.

You only get continued operation if *both* rings are "wired" and a break is confined to a single ring (you can support some breaks in *both* rings if you allow messages to transit from one ring to the other -- but this gets hokey)

It takes out that *one* bus. But, you have a second -- using a second pair of conductors (same number of wires that your dual ring requires!)

You can run the second multidrop bus "on a different path" just as well as you can run the CCW ring's cabling on that same "different path". I don't see why you think multidrop is more vulnerable or takes more wires/hardware?

Huh???

I'm confused too. Perhaps I haven't explained well enough.

We have two "logical rings" and one physical ring. So with your diagram of nodes A,B,C, there are two wires going from B to C and two completely separate wires going from B to A. Each device receives its own transmission. Between B and C, only one device can transmit at a time i.e. half duplex. B's transmissions to C are for the CCW ring and C's transmissions to B are for the CW ring.

The hardware transmits and receives a whole message at a time for us which saves a lot of interrupt overhead so we can't start transmitting early with the current hardware..

so

Messages go in both directions around the ring even though it's only 2 wire. If there's a break between 3 and 4, messages still get from 3 to 4 because they go round the other way as well. Every message placed on the ring goes in both the CW and CCW directions, except when two nodes are having a conversation with each other.

No, our "dual" ring only requires 2 wires.

Sorry, we have a special board that we drive from a single uart and it duplicates the tx onto each pair or wires and for rx it combines the two signals to give the uart rx a single character stream.

It can change -- or *not*! When you miss a start bit, all bets are off because your receiver is no longer in sync with your data. E.g., if you miss a start bit and are transmitting the value 0xFF (with no parity), then the line just looks COMPLETELY IDLE for one whole character time. OTOH, if you miss the start bit and are sending 0x55, then you could "receive" any of a number of different values in place of that 55...

When you are operating in an environment in which errors are not The Exception, it is hard to make *any* assumptions.

Because the start and stop bits are "out of band" (unless missing one puts them *in* band -- for another character time!)

But there are other ways to do that. E.g., passing along the message before it is completely received, etc.

But, is it true for each *ring*? I.e., in A->B->C->D->E->

you have stated that D won't be receiving while it is *sending* to E. This implies C won't be sending (to D) in this time. But, that doesn't preclude *B* from sending to C in this time! I.e., can there be more than one message circulating in each ring? If so, and the baud rate can be changed, how can you guarantee that messages don't start "rear ending" the ones ahead of them? I.e., if D downgrades its baudrate, any message that B is sending (to C) looks like it is "speeding"...

See above.

See above. This is where the use of coins/tokens on a graph can be useful -- you can see how the messages can potentially interact with each other.

So there is no way of a sender knowing that a recipient got a message intended for it?

When the baud rate changes between two particular (adjacent) nodes, there is effectively a discontinuity introduced. As you said, "the baud rate between any two nodes is independent of any other two nodes" so other nodes can be talking at FASTER (or slower) speeds. The time it takes to pass a message between any two nodes can then vary. Time is universally shared among all nodes. If D->E runs at 1200 baud and all other nodes are running at 57600 baud, then a message from A can get to B and then to C and then ... in the time it takes D to push a similarly sized message out to *E*. I.e., C has no way of knowing if D is ready to *listen* to C, yet, since C has no way of knowing if D has finished transmitting to E. C can't rely on the fact the time that was required for it to receive it's incoming message (from B) would be sufficient for D to have passed *its* message along!

OK, so when you change the baudrate on a UART, you interrupt traffic in *both* rings between that node and it's neighbor. E.g., when the *one* UART that connects B to C changes baudrate, then nothing can be flowing from B to C *or* C to B (i.e.,

They don't! But, if they aren't, then its more difficult to ensure that messages don't "collide". I.e., if someone downstream from you starts operating at a slower rate, then messages that *you* are sending can end up "there" before it is ready for them.

You *can* make this work. But, there are lots of ways it can *break*. That was Vladimir's point (elsewhere, up-thread). Especially if you are *expecting* to be operating (even temporarily) at the fringe of reliable communication!