I’m monitoring the received signal strenght of some xBee devices (now seven devices: routers, 485 adapters and DIO adapters) and I find that RSS info received from routers when sending a DB AT command is not right based on “XBee/XBee-PRO ZB RF Modules” manual (Table 10-010.RF Interfacing commands) that states that observed values ranges from -92 to -26 dBm (-88 to -26 if xBee-PRO).
What I see in my network is that 485 and DIO modules are in range, but routers are the most of the times out of this range showing values even lower to -100 dBm. Connectport web interface shows the same values so I discard an error managing AT response. About router locations, their distance to the coordinator is shorter than many of the other tested devices, so expected RSS levels might be better, but they aren’t.
Is it a firmware bug? Manual only states that DB AT command …does not provide an accurate quality measurement for a multihop link. Could be that the cause?
Well, keep in mind that the value you read is just the strength of the ‘last signal seen’.
It certainly is NOT promised to be the strength of the request which the coordinator sent to that router. It might be, but could easily be any other 802.15.4-level signal - I believe even a signal from an unrelated node. That is why the ‘multi-hop’ is different. Say you talk to router A via router B. You might have a horrible signal with B (can’t even see A), yet A might see B great and return a very good RSSI. So you’ll think your life is good because ‘A’ has a great signal, when in truth you can barely talk to it.
I also had a situation with 10 end-devices all about 400 feet away from the parent (the coordinator). It was always ‘pot-luck’ if they claimed the signal strength was ‘great’ or ‘poor’ - again, because end-devcies send a packet every 100 msec, it just depends on which packet was the last seen. I assume if the last packet was between coordinator and end-device, then RSSI was poor, but if the last packet was one of the beacons from anotehr child, then the RSSI was great.
Also keep in mind the antenna affects the value. I assume the 485 & DIO have the external RPSMA. What do your ‘routers’ have? 2cm of wire? A PCB trace? I would not expect them to have as good of signal with a smaller antenna.
I should add, on my own systems I use what I call an ‘availability’ value between 0% and 100%. I track all of the missed data updates and use that to ‘judge’ if my signal strength is good or not. On a good system it will be in the 98%+ range, whereas on a system a bad signal (& other noise issues) it could drop down towards 0%.
Hi Linnl. First, thanks for you reply, it exposes interesting facts. However I have to admit, event declaring me as an absolute xBee radio protocol lammer, that some points are not very clear:
…I assume if the last packet was between coordinator and end-device, then RSSI was poor, but if the last packet was one of the beacons from anotehr child, then the RSSI was great.
If I understand you are saying that, from an end device point of view, the received signal strength is not that related to the Coordinator transmission but that related to any network member transmission. I think it’s not right and I’ll try to expose why: In my network there are two nodes far from any router and coordinator, but one close to the other. The RSS levels from these nodes are the poorest of the network, but, based on your opinion, being one close to the other might improve the RSS read since one end device should see the other Also keep in mind the antenna affects the value.
I assume the 485 & DIO have the external RPSMA. What do your ‘routers’ have? 2cm of wire? A PCB trace? I would not expect them to have as good of signal with a smaller antenna. signal.
Nop, since all of them are xBee stuff all use the same xBee stock module with the 2cm cable antena.
Anyway, your explanation is solid and gives logical to the situation I see now, where the closest router has a decent signal while the other has a very low signal. But it’s important to state for other users that, once more, the info contained in the manual is not right since seen dBm levels are by far out of the claimed range.