Hi,
On netdev event: NETDEV_EVENT_TX_COMPLETE (after AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame received by at86rf2xx? @Thomas, @Hauke ?
Cheers,
Hi Baptiste!
Hi Baptiste!
On netdev event: NETDEV_EVENT_TX_COMPLETE (after AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame received by at86rf2xx?
The ACK frame is processed automatically by the transceiver. There is no way to access it using the extended mode. If you use the base mode, you will have to send and process the ACK yourself.
Ok I don't want to process the ACK myself, I only want to get the frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame store in a register/frame buffer? Or do we must use base mode to get the ACK frame.
Which mean that automated ACK by the transceiver is fine. 1 - RIOT sends a frame 2 - Transceiver receives an ACK and transmit a AT86RF2XX_TRX_STATE__TRAC_SUCCESS 3 - Here I want to get the ACK frame content 4 - Use it with openthread (Have a look here [1] to understand why we need it)
[1] https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404
Cheers,
Hi Baptiste,
you could try reading out the frame buffer after that although I am not sure the current mode of operation actually updates the frame buffer with the ACK frame. (The data sheet is also kind of unspecific on this.)
Other than that I don't see an easy solution, only porting the driver to basic operation mode.
Best, Thomas
Why do you need the actual ACK frame? It’s only like 3 bytes + FCS and doesn’t really contain anything interesting. The only interesting information is that the frame with the given sequence id was received properly, which is exactly the same information you get from the transceiver hardware.
Regards, Joakim
I guess if you only want to use the ACK frame as an input of the function, given that it is hard to get from the extended mode, then, maybe one solution is that you can manually build one yourself (you can get the sequence number from the hardware) and pass it to the function.
Cheers,
Shuguo
Yes Thomas I haven't tried yet but I don't think transceiver stores it. Joakim, OpenThread requires it as explained here: https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
Shuguo, this a hack solution. There is a way to use old function which does not required the ACK frame so we're going to use as long as it is possible.
Hi Baptiste!
OpenThread asks all new platform to use new function: otPlatRadioTxDone that requires ACK frame.
If you get deeper, I think they use it to get the power of the transmission and may be something else that I missed: https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993
Hi Oleg,
Hi Baptiste!
> Yes Thomas I haven't tried yet but I don't think transceiver stores it. > Joakim, OpenThread requires it as explained here: > pkg/openthread: add FTD-MTD-NCP tests by biboc · Pull Request #7149 · RIOT-OS/RIOT · GitHub
Sorry, I don't get the explanation. Why does OpenThread needs the pointer to the ACK frame?
Some IEEE 802.15.4 MLME-ops requires if the ack was received or not. This need be handled by upper layers e.g. a SoftMAC layer of IEEE 802.15.4. So actually if ARET is supported by hardware and it's an SoftMAC transceiver it should have the possibility to read out some status register of handled ARET algorithm on hardware side if ACK was there or not (because MLME-ops requires this information). If hardware can't report and is a SoftMAC transceiver with ARET support and can't handle MLME-ops on hardware side: you have a problem.
For my Linux experiments I tried to implement to make an upper layer report if ACK was there or not, see [0]. I didn't implement MLME-ops it was to keep per peer stats about link quality. Further this information for upper layer (mac802154) it's necessary for some IEEE 802.15.4 MLME-ops handled by this layer.
I think OpenThread needs also this information for some of "future or already?" handled MLME-ops.
Hi,
Hi,
Hi Baptiste!
If you get deeper, I think they use it to get the power of the transmission and may be something else that I missed: openthread/src/core/mac/mac.cpp at main · openthread/openthread · GitHub
Thanks for the pointer. So, OpenThread is basically not interested in the ACK itself, but the accompanying information like RSSI and/or LQI. Well, in that case, I guess there's no way around using the base mode of the at86rf2xx. Thomas once started a branch for that which seemed to work fine at a first glance: GitHub - thomaseichinger/RIOT at feat/rf2xx_basic_netdev2
Not sure how much work would be required to rebase it on current master. One would also need to check if OpenThread also takes care about sending ACKs and retransmissions itself.
Cheers, Oleg
Hi Alex!
Hi,
Hi Alex!
> > > Yes Thomas I haven't tried yet but I don't think transceiver stores it. > > > Joakim, OpenThread requires it as explained here: > > > pkg/openthread: add FTD-MTD-NCP tests by biboc · Pull Request #7149 · RIOT-OS/RIOT · GitHub > > > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to > > the ACK frame? > > > > Some IEEE 802.15.4 MLME-ops requires if the ack was received or not. > This need be handled by upper layers e.g. a SoftMAC layer of IEEE > 802.15.4. So actually if ARET is supported by hardware and it's an > SoftMAC transceiver it should have the possibility to read out some > status register of handled ARET algorithm on hardware side if ACK was > there or not (because MLME-ops requires this information). If hardware > can't report and is a SoftMAC transceiver with ARET support and can't > handle MLME-ops on hardware side: you have a problem.
Using at86rf2xx's extended operating mode allows you to figure out if an ACK was received or not, but not all models allows you to read if and how many retransmissions were necessary.
Question here is:
Is "how many retransmissions were necessary" is a required information for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a lack of support to implement IEEE 802.15.4, if not then this is some "extra" feature. Not sure if this information is required. Required information for some MLME-ops is if finally there was an ACK or NOT, no matter how many retransmissions was involved.
Such "extra" feature could only be useful to check how reliable a peer is, maybe?.
- Alex
Hi Alex!
> Using at86rf2xx's extended operating mode allows you to figure out if an ACK > was received or not, but not all models allows you to read if and how many > retransmissions were necessary.
Question here is:
Is "how many retransmissions were necessary" is a required information for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a lack of support to implement IEEE 802.15.4, if not then this is some "extra" feature. Not sure if this information is required. Required information for some MLME-ops is if finally there was an ACK or NOT, no matter how many retransmissions was involved.
Hm, you can still use the base operation mode and implement "everything" (i.e., ACK handling, retransmissions etc.) yourself. Hence, the transceiver hardware is capable - it's just a matter of implementation comfort.
Such "extra" feature could only be useful to check how reliable a peer is, maybe?.
True.
Cheers, Oleg