ng_at86rf2xx: fix wrong LQI and ensure 802.15.4 compliance with packet length field #2884
Conversation
| ng_at86rf2xx_fb_read(dev, &phr, 1); | ||
|
|
||
| /* Mask MSB for 802.15.4 compliance, see | ||
| * section 37.1.1.2 of SAM R21 datahseet |
There was a problem hiding this comment.
could you please reference the radio datasheets (-> it is section 8.1.1.2 for all four supported devices...)
|
@haukepetersen, are we all set here and ready to go? |
|
I would think so. Did anyone else test my changes? |
|
I test this as we speek |
|
Running this on the iot-lab and the samr21, I am not sure if the LQI values are correct (or actually I am not even sure what they should look like). If the LQI value should be fixed depending on the payload length, then everything works fine... |
|
I tested the LQI value yesterday in conjunction with the kw2x-device and the driver of #2756. I received a value between 100 and 220 or so, depending on the rssi. When the distance between both devices was close, the value was around 220, when increasing the distance the value dropped. According to the reference manual of the kw2x-device (p.113) this behaviour is correct. The RSSI-value can be calculated from the LQI-value. What should the RSSI-value look like in the NETIF-header? In general RSSI is the signal strength in dBm, so a value of -100 to -20 should be appropriate. Is the sign in this case just omitted? |
|
On the samr21, I observe the same behaviour than @haukepetersen, LQI depends on the payload... |
|
So to me it still seems to broken with this PR? |
|
If the at86rf2xx does not provide a working LQI, maybe you can calculate this value. In the Freescale KW2x device it is opposite; the RSSI-value is not provided, but it can be calculated using the LQI. Do we really need both values for the upper layer? Since they seems to be directly related to each other one of the values would be sufficient. |
Actually they aren't. RSSI and ED give you information about the signal power on your channel. This include of course noise and other signal sources (e.g. WLAN). LQI on the other hand is an indicator for the actual received signal quality.
The extracts are taken from AT86RF233 datasheet on page 110. |
Actually I think the devices do, it is just a question of reading the right value :-) |
|
So I checked again and I can't seem to find the error. I looked at the raw framebuffer which looks good. Some header, payload, CRC and then 3 never changing bytes. I double-checked how Atmel is getting their LQI in lwMesh and they also read the first Byte after the CRC checksum as LQI. I found out that LQI is only valid in 250kbp/s mode and when the payload is greater than 2 octets, which I checked is both met. I observed that even if the 3 Bytes after the checksum (FCS field) seem to be static when transmitting the same payload, the last 2 Bytes (ED, RX_STATUS) change when power cycling the board. That seems kind of strange, so I suspected that it's some kind of SPI or maybe data handling error. That's where I am now. I had a look at the SPI driver. Even though there are some strange things happening, they should have no effect on my observations. Maybe it's some kind of harfware fault? If nobody comes up with an idea I would open a ticket at Atmel support I guess. |
|
@daniel-k, you were deep in your observations so oppening a ticket is what you should do now IMO. |
|
Asking Atmel about this seems the right way to go. @daniel-k, will you do that? |
|
Already did 2 days ago, now waiting for a response. I also linked them this issue, so let's wait. |
|
@daniel-k, any answer from ATMEL? |
|
@bapclenet There was a reply, but no answer / solution yet. But we'll get there. |
|
@daniel-k, any news then? |
|
@bapclenet I was quite busy the last week, but today I managed to redo my measurements and sent them to Atmel again. They advised me to try their Wireless Performance Analyzer. I'll do that soon. Here are my finding regarding LQI values: http://docdro.id/11n0h This looks really strange, doesn't it? |
So yes, this is definitely strange! At 10cm, it should be 255 everytime. Either the way we get LQI is wrong or there is an hardware problem. Let's see what ATMEL says about it. |
|
Maybe 10cm are too close and cause some kind of near field effect? |
|
@OlegHahm I got similar results with incresed distance. And either way it would be a huge drawback in system design if this wouldn't work that way IMO. |
|
I think it was worth a try and it's not uncommon that radios have problems at low distances due to crosstalk. |
|
I just went outside and arranged the boards at about 1m away from each other, turned Wifi of my notebook off. I got surprisingly low RSSI values, but the same (swinging) scheme of LQI. |
Some weeks ago I tested this setup with two KW2x radio modems. The closer the distance between both antennas was, the higher was the LQI I received. So I could not observe some kind of near field distorion. But HF is always some kind of magic and generalization is difficult ;). |
|
So Atmel wants me to flash their Performance Analyzer Software to test the board. Unfortunately I don't have access to a Windows PC at the moment and running Atmel Studio inside a VM doesn't seem to work for me (USB not recognized). Maybe someone else can try this? They sent me these links: |
|
@kaspar030, haven't you found a way to run this Atmel software inside some Windows VM? |
|
@daniel-k, @haukepetersen, ping |
|
Nothing new from my side. Waiting for someone to try. |
|
Ok, I'm on it, what do you me to do with the Performance Analyzer Software? Look at LQI value? |
|
@bapclenet Thanks for your commitment! I would have done their tests while watching the LQI value. See this document where I ran tests with RIOT. From there it looks like LQI is coupled somehow to frame length OR there is something going wrong badly in our driver. But I don't know. And I never used Atmel Studio either ... |
|
@daniel-k, My conclusion would be that we don't get the right LQI value, sorry. |
|
|
Seems so. I really don't have a clue why. How are we going to proceed? If our investigation doesn't yield success, at least we should disable the LQI for this driver. |
|
Have had a look at Atmel examples? |
|
@daniel-k ping |
| @@ -293,7 +293,8 @@ static void _receive_data(ng_at86rf2xx_t *dev) | |||
| /* fill missing fields in netif header */ | |||
| netif = (ng_netif_hdr_t *)hdr->data; | |||
| netif->if_pid = dev->mac_pid; | |||
| ng_at86rf2xx_rx_read(dev, &(netif->lqi), 1, pkt_len); | |||
| /* LQI offset: Payload (pkt_len) + FCS (2 byte) */ | |||
| ng_at86rf2xx_rx_read(dev, &(netif->lqi), 1, pkt_len + 2); | |||
There was a problem hiding this comment.
Looking at section 38.3.2 of the samr21 reference it seems there has to be one additional offset byte as PHR has offset 0. Right?
While the offset should be fine for rf231 modules.
There was a problem hiding this comment.
In general yes, but you need to have a look at the implementation:
void ng_at86rf2xx_rx_read(ng_at86rf2xx_t *dev, uint8_t *data, size_t len,
size_t offset)
{
#ifndef MODULE_NG_AT86RF231
ng_at86rf2xx_sram_read(dev, offset + 1, data, len);
#else
ng_at86rf2xx_sram_read(dev, offset, data, len);
#endif
}|
@bapclenet In the case they use the LQI value, they only use the upper 2 bits and multiply this with the ED value (and something more, but constant). I looked again in the datasheet of the RF233 with the hope to find something I missed, but nope. There are guys using the RF230 [1] that seem to get sensible LQI readings. So I more and more get the impression that something is wrong the RF chip inside the SAM-R21. At least I don't have a clue what should go wrong otherwise. |
|
If your assumption is right, we should be able to get proper readings on other at86rfxx boards, e.g. the IoT-LAB_M3, right? |
|
See #3954 for fixing LQI. Masking PHR will have a separate PR. |
This PR should fix wrong LQI values for the new driver and adds additional measures to ensure IEEE 802.15.4 compliance regarding the PHR field as suggested by the datasheet and already discussed in #2825.