Wireless packet data transmission
 

Hello again!

I know some of you guys deal with propagation effects, so I figured I
could ask a related question.

In my understanding, a packet is just a way to sectionalize and
categorize individual bits. One group would represent the destination/
address/header. Another would be the actual data (or payload), and
then, maybe a trailer section. Is this a correct assumption?

In wireless transmission, where multipath effects are present, how
does the receiver actually "know" if the order of bits are correct
when processing the packets?

Thanks!

Wireless packet data transmission
 

"MRW" wrote in message
...
Hello again!

I know some of you guys deal with propagation effects, so I figured I
could ask a related question.

In my understanding, a packet is just a way to sectionalize and
categorize individual bits. One group would represent the destination/
address/header. Another would be the actual data (or payload), and
then, maybe a trailer section. Is this a correct assumption?

In wireless transmission, where multipath effects are present, how
does the receiver actually "know" if the order of bits are correct
when processing the packets?

Thanks!

they include a checksum to check the data. basically you take all the data
bytes in the packet, add them together, and compare that to a number in the
header. if they match its good, if not you throw it away and request a
repeat.

Wireless packet data transmission
 

In article ,
MRW wrote:

Hello again!

I know some of you guys deal with propagation effects, so I figured I
could ask a related question.

In my understanding, a packet is just a way to sectionalize and
categorize individual bits. One group would represent the destination/
address/header. Another would be the actual data (or payload), and
then, maybe a trailer section. Is this a correct assumption?

That's a fairly good basic model for how many packet transmission systems
work.

In wireless transmission, where multipath effects are present, how
does the receiver actually "know" if the order of bits are correct
when processing the packets?

Most packet transmission systems incorporate some form of integrity
checking within the packet itself. This may be as simple as a
checksum (add up all of the bytes in a given portion of the packet and
append the sum), or a cyclic redundency check (CRC16 or CRC32), or
something more sophisticated. The receiving system will (in effect)
re-compute the checksum or CRC or other validity-check value, based on
what it actually receives, and will discard the packet if the embedded
check value doesn't match what it computes (which indicates that there
was at least one bit not correctly received).

This error-checking architecture doesn't distinguish between the
various effect of multipath (e.g. intra-symbol interference / fading
from short multipath delays, or inter-symbol interference from longer
delays) and other forms of noise or distortion (other transmissions,
static or other impulse noise, etc). It operates strictly at the
level of the data bits. If the bits don't arrive intact (for whatever
reason) the packet is discarded. It may, or may not, send back a
"Hunh? What was that? Please repeat, answer foggy"
negative-acknowledgement symbol, depending on the protocols in use.

The error checking may be performed by the low-level modulation
hardware, by a host CPU, by firmware running in the communications
controller / MAC, or some combination of these.

Over-the-air protocols which are used on communications paths which
are known to suffer from serious multipath and fading effects may
incorporate FEC (forward error correction) - redundent data included
in the packet, computed by the sender, which can be used to recover
the correct packet data even if some bits are entirely wiped out in
transmission, without requiring that the packet be retransmitted.
Adding FEC necessarily increases the size of the packet and reduces
transmission bandwidth, but the *useful* bandwidth is often still
higher than you could get without FEC thanks to the reduction in the
number of packets which must be retransmitted.

--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

Wireless packet data transmission
 

MRW wrote:
Hello again!

I know some of you guys deal with propagation effects, so I figured I
could ask a related question.

In my understanding, a packet is just a way to sectionalize and
categorize individual bits. One group would represent the destination/
address/header. Another would be the actual data (or payload), and
then, maybe a trailer section. Is this a correct assumption?

In wireless transmission, where multipath effects are present, how
does the receiver actually "know" if the order of bits are correct
when processing the packets?

Thanks!

Google "Cyclic Redundancy Check." Or, CRC for short ...

Regards,
JS

Wireless packet data transmission
 

On Nov 21, 6:26 pm, (Dave Platt) wrote:
In article ,

MRW wrote:
Hello again!

I know some of you guys deal with propagation effects, so I figured I
could ask a related question.

In my understanding, a packet is just a way to sectionalize and
categorize individual bits. One group would represent the destination/
address/header. Another would be the actual data (or payload), and
then, maybe a trailer section. Is this a correct assumption?

That's a fairly good basic model for how many packet transmission systems
work.

In wireless transmission, where multipath effects are present, how
does the receiver actually "know" if the order of bits are correct
when processing the packets?

Most packet transmission systems incorporate some form of integrity
checking within the packet itself. This may be as simple as a
checksum (add up all of the bytes in a given portion of the packet and
append the sum), or a cyclic redundency check (CRC16 or CRC32), or
something more sophisticated. The receiving system will (in effect)
re-compute the checksum or CRC or other validity-check value, based on
what it actually receives, and will discard the packet if the embedded
check value doesn't match what it computes (which indicates that there
was at least one bit not correctly received).

This error-checking architecture doesn't distinguish between the
various effect of multipath (e.g. intra-symbol interference / fading
from short multipath delays, or inter-symbol interference from longer
delays) and other forms of noise or distortion (other transmissions,
static or other impulse noise, etc). It operates strictly at the
level of the data bits. If the bits don't arrive intact (for whatever
reason) the packet is discarded. It may, or may not, send back a
"Hunh? What was that? Please repeat, answer foggy"
negative-acknowledgement symbol, depending on the protocols in use.

The error checking may be performed by the low-level modulation
hardware, by a host CPU, by firmware running in the communications
controller / MAC, or some combination of these.

Over-the-air protocols which are used on communications paths which
are known to suffer from serious multipath and fading effects may
incorporate FEC (forward error correction) - redundent data included
in the packet, computed by the sender, which can be used to recover
the correct packet data even if some bits are entirely wiped out in
transmission, without requiring that the packet be retransmitted.
Adding FEC necessarily increases the size of the packet and reduces
transmission bandwidth, but the *useful* bandwidth is often still
higher than you could get without FEC thanks to the reduction in the
number of packets which must be retransmitted.

--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

Thank you so much, Dave! This has made it more clearer.