1These are just development notes.
2
3* Some protocols/stacks will look into the data even before the packet is CRC'ed. This can be the case both for
4  the BLE header & the 802.15.4 "header" (actual phy payload).
5  Today the Phy provides an uncorrupted packet, so the device cannot directly behave like if it received the possibly corrupted one, and be fully correct.
6  Some protocols will check the header (in SW or HW), but also may have FEC in this headers.
7
8  Today the options for the device are to either
9   * or to assume no errors while doing the ongiong packet parsing, and have a too good performance (only react to the CRC errors eventually discarding the payload)
10   * when the phy says that either the header or payload is corrupted, always assume the erros in the some places (say in the worst case place)
11   * or to do its own random draw to decide where exactly errors are.
12
13  Trying to model more precise different protocol options here would lead to be a very complex Phy state machine and protocol w devices
14
15  A more general solution would be the Phy providing to the device a bit error mask
16  as that would allow to generate the corrupted packet in the lowest layer of the device, and have it feed that to the radio models/stack.
17  The issue with such a solution though, is that as some stacks look into as much packet as possible on the fly, that would require this bitmask to be updated on the fly.
18  An option would be to allow the device to request an update to this bitmask during each abort reevaluation.
19  That is, a new IMMediate procedure, something like:
20    imm_req_error_mask:
21      byte_array_start_offset //just to save BW, how many bytes to chop from the array (that it already got before)
22    imm_resp_error_mask:
23      current instant
24      header_start //offset in bits in the array that marks the begining of the header, before that it would be preamble + address
25      already calculated bit array lenght //how much is actually filled. (At the very least we will send full bytes)
26      bit array lenght //number of actual bytes that follow
27      error bit array itself[]
28
29* Model the lenght error, by asking the receiver until when will it wants to receive, and then maybe continuing after the tx end
30  specially interesting for errors in the code indicator (and also lenght errors)
31  Either in the initial Rx request, or after
32  For after maybe also with an immediate command just to set that length,
33  and a new structure after RXCONT in which the device can provide both this lenght, and a new abort structure.
34  forced_packet_duration was added in the Rx struct for this.
35
36* In piggybacking receptions, if the modulation or coding rate is incorrect, it should lose bits
37  The same should be done if the packet disapears.
38  Internally we should flag it first time it is detected, and then just lose bits afterwards until the end (otherwise if another packet is transmitted from the same tx we may mistake it as good)
39
40* Once the Tx is lost, today the Phy counts everything as errors.
41  It should instead have a 50% prob. of bit errors
42
43* Compatible modulations with different coding rates are not handled too well.
44  The receiver would sync but that would actually cause bit errors
45  for ex. 125 and 512 coded phy, or other similar coderate disparities.
46  The coding_rate was added in the Tx and Rx structures.
47  Logic shuold be implemented
48