RE: Re: [OpenGarages] Will Superposition of error flags desynchronize a active-transmitter passive-receiver bus??
"John Dammeyer" <[email protected]> Tue, 21 Aug 2018 09:19:57 -0700
| Newsgroups | gmane.comp.hardware.bus.can |
|---|---|
| Message-ID | <[email protected]> |
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?? >=20 > Conventions: > _ =3D 0 =3D dominant bit > - =3D 1 =3D recessive bit >=20 > Imagine the signal: > ______----------- >=20 > That is, 6 dominant bits + 11 recessive bits. >=20 > If my previous interpretation of ISO was correct (I think that it = wasn't), so: >=20 *** 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: > ______----------- > =3D > error flag (6 dominant bits) + > error delimiter (8 recessive bits) + > intermission (3 recessive bits) >=20 > Now Node1 thinks that bus is idle and if Node1 has information to = transmit, > it will send a SOF. *** Correct. >=20 > However, > Node2 will interpret the same signal as follow: > ______----------- > =3D > 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 >=20 > When Node1 thinks that it can send a SOF, Node2 thinks that it is = inside the > error delimiter. >=20 > -- >=20 > 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. >=20 > 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. >=20 >=20 > > 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 =3D 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 =3D transmitter, active-error-node > > > node 2 =3D 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]>