uracoli-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [uracoli-devel] General question about large payloads


From: Joerg Wunsch
Subject: Re: [uracoli-devel] General question about large payloads
Date: Mon, 12 Sep 2011 23:10:07 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

As Charles Goyard wrote:

> At some point I will want to extend that to 100 objects. Would it
> then be better to send one large packet with a 102-bytes payload, or
> to break it into smaller pieces ? Better is to understand from a
> "probability to get a large packet unaltered".

Of course, the longer the packet, the higher the chance that one bit
might be corrupted, so the entire packet has to be retransmitted.

However, in practice, that will probably only become an issue if
you're already working at the brink of the link budget.  Remember,
there's already quite a bit of redundancy in the normal IEEE 802.15.4
signal, which allows for signals to be detected 10 dB (or a little
more) below the noise level.  For your flying balls, I guess there
will probably be short moments where you might get failed
transmissions, but that should be covered still well in time using the
normal packet retransmission procedure, as the flying ball quickly
leaves the spot of the bad transmission path again.

With a 102-byte payload, just keep an eye on the MAC-layer overhead,
to not exceed the maximal packet size (127 octets).  With two octets
of FCF, one octet sequence number, two octets FCS (CRC-16), and
assuming two long addresses without PAN ID compression, the MAC
overhead would already become 25 octets, thus just reaching the
maximum packet size.  Of course, you'd normally use short addresses,
and also PAN ID compression, saving you another 14 octets.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]