On Sat, 16 May 2009, Dario Greggio wrote:

> sergio masci ha scritto:
> >> I wanted to place a question for you all. I can't see a "frame id" i.e. 
> >> a counter in the above protocol: I found it mandatory to deal with 
> >> repeated packets and retransmission.
> >>
> >> What do you think about this?
> > 
> > Yes I also belive it should be mandatory. For one thing it helps 
> > acknowledgement of packets that arrive out of sequence.
> 
> Yep, I've been about this in the night, and actually Gerhard reply, 
> saying that it can be placed at a higher level in the Protocol, makes 
> sense. In my case it's not like this, at the moment. of course the 
> overall result is the same, just a matter of cleanness of protocol and 
> level.

I am not contradicting Gerhard here. Yes the packet ID could be placed at 
a higher level in the protocol stack but so could many other things. 
Personally I'd push it way down and have fewer layers. I would justify 
this by saying: if every packet has X, Y and Z components and these 
components can be easily maintained by a low level layer then why bother 
extracting one of these componets into a higher layer. When talking about 
tiny MCUs more layers tends to equal more cost (code and variable space).

> 
> 
> > For multi master collision detection, have you considered sending back the 
> > CRC as part of the ACK. If two masters have both sent packets and have not 
> > seen a collision and a slave has also seen a valid packet from one of the 
> > masters, sending back the CRC will inform (probably) one of the masters 
> > that there was a collision. Maybe include the ID of the node that the ACK 
> > is intended for?
> 
> Not sure what you mean here , Sergio.
> In my case, the ACK is a message on its own and not barely a flag in the 
> Frame.

Many protocols I have encountered simply involve sending a packet from 
node A to node B and node B responds with a simple ACK or NACK (or 
sometimes just times out) and then node A retransmits or proceads with the 
next packet. I've even seen this where multiple nodes can start talking at 
the same time.

> If 2 masters send a packet to the same slave, there will be 
> either a collision or the slave may receive only one of them and miss 
> the other. In the 1st case, both masters will retry

As has already been mentioned, neither master might see the collision.

> (maybe after a 
> random delay - though often the devices will send packets after a human 
> event, say a button press, which is random inherently), with the same 
> FrameID and will wait for ACK again; in the 2nd case, the 1st master 
> will be ok and the second will retry and, then, get a reply.
> 
> So, yes, the replied ACK includes the destination ID (the master who 
> sent the command in first place).

So we think the same here. Does the ACK include the packet ID of 
the packet being ACKed?

Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist