1. to support multiple sends through the ascynronous radio send interface the send() must return error_t to indicate it cannot service more 2. to have guaranteed timing we need guaranteed access to the send interface, so we cannot have multiple sends through the radio send interface. 3. time critical tasks: CCA -> TX-DATA RX-DATA -> TX-ACK TX-DATA -> RX-ACK 4. after the CCA we need to send data, but then TX-DATA cannot wait for the completion of a receieved packet (maybe we should), so maybe we should not have concurrent receives with everything else, enable receive only when needed 5. if there are no multiple sends in the radio send interface, then to have robustness, the separate interfaces should record the requests until they are ready to service them 6. to support receiving messages in the TX-DATA -> RX-ACK gap that need to be acknowledged we must have a TX-ACK queue (we do not want to saturate the channel while waiting for ACK). If this gap is large, then many messages could accumulate that have not been acked, which can get out of control 7. for low power listeing the TX-DATA -> RX-ACK -> TX-DATA gap should be minimal to have the best duty cycle possible (maybe with a pair of CCA checks it is possible to cover the gap). 8. if only single requests are serviced by the radio send interface, then there is no need for the message pointer in the sendDone event. 9. the receive buffer cannot service the higher layer via the asynchronous radio receive interface (or there should be another buffering down the road) that is pumped with a task. Also, the sendDone event must be fired from a task too. 10. if a valid packet is received in the TX-DATA -> RX-ACK gap, then we could fail the TX-DATA but accept the RX-DATA. This requires two events to be fiered: sendDone(FAIL) and receive(msg). We cannot fire the sendDone first because then our component does not become ready, and the higher layer might want to transmit again instead of listening (needs buffering) 11. four ways to handle the receive data while waiting for ACK problem a) drop these packets, b) drop only those that need acknowledgements, c) buffer them at the acked send layer (needs message_t) and deliver them when receiving is allowed again d) deliver them before signaling the sendDone(FAIL), but then we have to allow concurrent receives with sends 12. It is very problematic to receive unexpected packets, what to do with these? They could occur in the following gaps a) CCA -> TX-DATA b) RX-DATA -> TX-ACK c) TX-DATA -> RX-ACK 13. The hidden terminal problem can occur at 12b), i.e. NodeA transmits that is received by NodeB but not heard by NodeC, which starts to transmit before NodeB could send an acknowledgment. 14. with dedicated receive start calls, a) we could set the channel there, b) would have no problem with unexpected receives c) could set a timeout parameter d) need cancel command in the asynchronous receive interface e) after receive we could go to PLL_ON state, could always download frame 15. async send done could return an error code to indicate that something went wrong, for example the CCA did not complete or the channel was busy 16. If we want to cancel the receive process, then it is not clear what to do in the BUSY_RX case. We could either go with FORCE_TRX_OFF and then PLL_ON, or do a PLL_ON and wait for the completion of the received message. Therefore once we are in the RX_ON state, we cannot guarantee to start TX_ON precisely. We need to verify this. 17. We need to transmit and cancel the listening process because of user input. The listening cancelling is not atomic (we might need to receive messages) and then send acknowledgment etc. Either we are always listening (conccurent receive / transmit) or call cancel and wait for receive(ECANCEL). 18. The CC2420 has a receive queue, that needs to be flushed. This mean that we might not able to prevent more than one message to arrive when listening. So we are either always on, or need purge functionality to receive all messages from the receive queue. 19. The RF230 does not support promisculous mode, so in general we cannot use the hardware TX-ACK feature with the RX_AACK command. 20. With software acknowledgements on the RF230 we cannot reply to a RX-DATA with a TX-ACK faster than at least 200 microsec, because we need to download the full frame, check the CRC and only then we can send the ACK to avoid acking corrupted frames. This means that item 13 is a real problem, and we should go with item 11 d). Receiving a data packet while waiting for an ACK should fail the previous transmission and send an ack for the incoming frame. 21. We cannot receive a message while a transmission is in progress because what would an ack layer do in this case? It cannot send the acknowledgment because a send is in progress. So send should return an error_t and while a send is in progress no receive is going to be fired. 22. If we use dedicated receive start calls, then an uxpected message can arrive (such as when waiting for ACK but getting some DATA), in which case the returned message_t pointer might be something else than the one with which the receive command was called. So in this case we need to return the message with the messageDone event. 23. What do we do with a received DATA packet while waiting for an ACK packet? We cannot signal higher layers that we have received it because the receive command was not called, so we have to buffer it, which can be problematic.