Rx
Rx
Tx.start_packet_time
Tx.start_p...
Tx.end_packet_time
Tx.end_packet...
Packet if it were not truncated
Packet if it were not trunca...
t
t
Tx.start_tx_time
Tx.start_t...
preamble + sync word
preamble + sync word
opt. header
opt. header
payload
payload
Tx.start_packet_time
Tx.start_p...
Tx.end_packet_time
Tx.end_packet...
t
t
preamble + sync word
preamble + sync word
opt. header
opt. header
payload
payload
a)
a)
b)
b)

Rxv2 examples and parameter explanation:

(See figure a) ) The transmitter defines the packet start (assuming no truncation) and the packet end (and therefore its total duration).
The receiver specifies the packet layout (according to the modelled protocol and how much automatic support it wants from the Phy).
The receiver specifies: 
* The duration of the preamble and address/sync flag: This specifies for how long the Phy will keep the Rx in "sync'ing" mode.
* The lenght of an optional header (which can allow the device to get separate information about bit errors in this area. During the header the Phy keeps that interface in "header" mode.
If there is a successfull sync, the phy will automatically do an RSSI measurement at the end of the sync word and report it in the rx_done structure. Together with the instant in which the syncword ended.
The Phy also reports the instant in which the procedure ended: this may be the end of the packet for a full reception, the abort time for an aborted reception attemp, or the end of the scan window for a failed (no sync) reception attempt.

Note that in all cases it is possible to "abort" the reception at any point. The content of the rx_done structure will then depend on how far the reception attempt progressed.
It is also possible for the receiving device to request instantaneous RSSI measurements at any point (during the abort reevaluation times)



Rxv2 examples and parameter explanation:...
Rx.pream_&_addr_duration
Rx.pream_&...
Rx.header_duration
>= 0
Rx.header_...
Rx_done.rx_time_stamp
(and RSSI meas time)
Rx_done.rx...
Rx_done.end_time
Rx_done.en...
Rx.start_time
Rx.start_t...
Rx.acceptable_pre_truncation
Rx.accepta...

(See figure b) ) It is possible for the receiver to be started/opened after the packet preamble start and maybe still receive the packet.

How late into the preamble can this be is defined by the "aceptable_pre_truncation" parameter.
Similarly how much of the preamble a transmitter may have truncated, while keeping the reception viable is defined by this same parameter.

That is, a receiver needs to be opened no layer than tx.start_packet_time + Rx.acceptable_pre_truncation, and the Tx.start_tx_time must be equal or smaller than tx.start_packet_time + Rx.acceptable_pre_truncation for that transmission to be possibly received


(See figure b) ) It is possible for the receiver to be started/opened after the packet preamble start and maybe still receive the...Text is not SVG - cannot display