Re: RE: [OpenGarages] Will Superposition of error flags desynchronize a active-transmitter passive-receiver bus??
"Christiano SA" <[email protected]> Tue, 21 Aug 2018 20:00:13 +0200
| Newsgroups | gmane.comp.hardware.bus.can |
|---|---|
| Message-ID | <trinity-8e03655b-0331-4bf9-90f4-5c9b133a0052-1534874413463@3c-app-mailcom-lxa04> |
> *** No I don't think so. Node 2 detects Stuff Error at this point, not an error flag, so Node 2 will start a Passive Error Flag expecting dominant bits but read recessive bits. Until it sees a properly formed error flag or bus idle, Node 2 will not receive any messages. It's likely the 8 recessive bits and the 3 intermission bits (11 bits) will reset the Node2 state machine since it's error passive. It will therefore correctly detect the next message. > Ok, correcting: Node2 will interpret the same signal as follow: ______----------- = ___ => Normal dominant 3 bits (it doesn't know that an error happened in the Node1 ) + *** Error detected!! Wrong Stuffing. (Suppose there was others dominant bits before) ___ => Trying to get 6 equal, failed with 3 dominant ------ => Trying again: OK! 6 equal recessive bits, the passive error flag is complete! (as the ISO says) + ----- => error delimiter ( it has 8 recessive bits but the signal presents only 5 of them) > *** So you are saying that the bus is noisy and Node 2 only sees 5 recessive bits before a dominant appears? No, I just was saying that the same 17 bits would be interpreted differently by two nodes; while Node1 might see a SOF, Node2 is yet inside the error delimiter. I will try draw it below: 0123456789abcdefg ______----------- Node 1: [0,5] = error flag [6,d] = error delimiter [e,g] = intermission Node 2: [0,2] = normal operation (data frame) Error happens because stuffing [3,5] = error flag field (trying to get 6 equal bits, but fail) [6,b] = error flag field (trying to get 6 equal bits, success) [c,g] = error delimiter (show only 5 bits) > ***Are these questions for a school assignment? No. Now I will draw the same analysis using the interpretation which a Think is correct: 0123456789abcdefg ______----------- Node 1: [0,5] = error flag [6,d] = error delimiter [e,g] = intermission Node 2: [0,2] = normal operation (data frame) Error happens because stuffing [3,5] = error flag field (trying to get 6 equal bits, but counting the previous 3 dominant bits, success, error flag is complete) [6,d] = error delimiter [e,g] = intermission Notice: The two nodes now are synchronized. I tried to get a "bug" using this approach but it works correctly always, therefore I think that it is the correct interpretation. > Sent: Tuesday, August 21, 2018 at 1:19 PM > From: "John Dammeyer" <[email protected]> > To: [email protected] > Subject: RE: [CANLIST] Re: [OpenGarages] Will Superposition of error flags desynchronize a active-transmitter passive-receiver bus?? > > See below: > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Christiano SA > > Sent: August-21-18 6:25 AM > > To: [email protected] > > Cc: [email protected]; [email protected] > > Subject: [CANLIST] Re: [OpenGarages] Will Superposition of error flags > > desynchronize a active-transmitter passive-receiver bus?? > > > > Conventions: > > _ = 0 = dominant bit > > - = 1 = recessive bit > > > > Imagine the signal: > > ______----------- > > > > That is, 6 dominant bits + 11 recessive bits. > > > > If my previous interpretation of ISO was correct (I think that it wasn't), so: > > > > *** Missing in this scenario is _why_ Node 1 is generating the Error Flag. Assuming a bit error? The previous bit was recessive when it should have been dominant? Therefore Node 1 will _generate_ what follows. > > > Node1 will interpret it as follow: > > ______----------- > > = > > error flag (6 dominant bits) + > > error delimiter (8 recessive bits) + > > intermission (3 recessive bits) > > > > Now Node1 thinks that bus is idle and if Node1 has information to transmit, > > it will send a SOF. > > *** Correct. > > > > However, > > Node2 will interpret the same signal as follow: > > ______----------- > > = > > error flag (6 dominant bits) + > > *** No I don't think so. Node 2 detects Stuff Error at this point, not an error flag, so Node 2 will start a Passive Error Flag expecting dominant bits but read recessive bits. Until it sees a properly formed error flag or bus idle, Node 2 will not receive any messages. It's likely the 8 recessive bits and the 3 intermission bits (11 bits) will reset the Node2 state machine since it's error passive. It will therefore correctly detect the next message. > > > 6 equal recessive bits + > > error delimiter ( it has 8 recessive bits but the signal presents only 5 of > > them) > > *** So you are saying that the bus is noisy and Node 2 only sees 5 recessive bits before a dominant appears? If Node hasn't seen the correct 'form' of the message it will once again send passive error flags. Until Node1 one finishes and creates an bus idle condition Node 2 will not receive messages. > > *** However now you no longer have Node1 receiving an ACK and therefore it transmits an Error Flag after the ACK. So your Node 2 will have another chance to synchronize to Node 1. > > ***Are these questions for a school assignment? > > John Dammeyer > > > > When Node1 thinks that it can send a SOF, Node2 thinks that it is inside the > > error delimiter. > > > > -- > > > > The correct interpretation probably is to think the "6 subsequent bits", as > > the ISO says, may have its left edge before of the detection of error > > condition. > > Such interpretation works very well with all cases that I have tested. > > > > Following such interpretation and applying to previous example, when > > Node2 detect a error condition, it has only 3 bits additional in order to > > complete 6 subsequent equal bits and the two nodes would be > > synchronized. > > > > > > > Sent: Monday, August 20, 2018 at 4:55 PM > > > From: "Collin Kidder" <[email protected]> > > > To: [email protected] > > > Cc: [email protected] > > > Subject: Re: [OpenGarages] Will Superposition of error flags > > desynchronize a active-transmitter passive-receiver bus?? > > > > > > I don't think it's a problem. The error delimiter is to be 8 bits and > > > the interframe space is 3 bits so it seems to me that there will be > > > 8+3 = 11 recessive bits minimum at the end of an error frame. That > > > ought to be plenty of bits to get everyone on the same page before > > > another frame tries to come through. > > > On Mon, Aug 20, 2018 at 3:02 PM Christiano SA <[email protected]> > > wrote: > > > > > > > > Imagine the following situation: > > > > > > > > You have a bus with two nodes: > > > > node 1 = transmitter, active-error-node > > > > node 2 = receiver, passive-error-node > > > > > > > > Now an error happens at node 1. As it is a active node, it will transmit 6 > > dominant bits, but... lets suppose that the third bit generate an error in the > > node2. > > > > > > > > The ISO 11898-1:2015, in the page 35 says: > > > > > > > > """"""""""""""""""""""""""""""""""""""" > > > > Passive error flags initiated by receivers shall not be able to prevail over > > any activity on the bus. > > > > Therefore, error-passive receivers shall always wait for 6 subsequent > > equal bits after detecting an error condition. > > > > The passive error flag is complete when these 6 equals bits have been > > detected. > > > > """"""""""""""""""""""""""""""""""""""" > > > > > > > > So, from node2's view, it will have to wait 3 (6 total - past 3) dominant > > bits + 6 recessive bits to follow the rule "6 equal subsequent bits". At the > > end, node2 can enter in the "error delimiter". > > > > However, from the node1's view, it is remaining only 3 bits to enter in > > the "error delimiter". > > > > > > > > Isn't it happening desynchrony here? > > > > > > > > This question is being sended to 2 mailing lists: > > > > Canlist > > > > Opengarage group > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "Open Garages" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected]. > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > You received this message because you are subscribed to the Google > > Groups "Open Garages" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > -- > > Archives and useful links: http://groups.yahoo.com/group/CANbus > > Subscribe and unsubscribe at www.vector.com/canlist/ > > Report any problems to <[email protected]> > > -- > Archives and useful links: http://groups.yahoo.com/group/CANbus > Subscribe and unsubscribe at www.vector.com/canlist/ > Report any problems to <[email protected]> > -- Archives and useful links: http://groups.yahoo.com/group/CANbus Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to <[email protected]>