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]>