Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Photon/P1] WICED SDK reports positive WiFi.RSSI() values for strong WiFi signal #1180

Closed
technobly opened this issue Nov 18, 2016 · 7 comments

Comments

@technobly
Copy link
Member

commented Nov 18, 2016

Tested on three different routers, occuring with Photon and P1.

Problem: If you get too close to the Wi-Fi AP, within a few inches of the antenna, the WiFi.RSSI() results start going positive! It should never be higher than -1dB. All positive values in the Particle API for WiFi.RSSI() are considered errors.

RSSI is a relative measurement, and is calibrated and given an offset (-1dB) based on a original transmitter strength by the MFG of the radio chipset. If that RF strength is exceeded, the original offset can be exceeded, as is happening here. The results should be bound to -1dB though, despite the strength of the transmitter.

This is most likely a bug in the WICED SDK, but could possibly even be a limitation of the BCM43362 Wi-Fi chipset.


Completeness:

  • Minimum test case added
  • Device, system and user firmware versions stated (v0.6.0)

@technobly technobly added this to the 0.7.0 milestone Jan 17, 2017

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Jan 20, 2017

I've just checked WICED sources and this seems like an error with documentation. WICED wwd_wifi_get_rssi() actually reports dBm, where positive values just mean we are over 1mW.

@technobly

This comment has been minimized.

Copy link
Member Author

commented Jan 20, 2017

Our API is such that it limits positive values to represent errors, so we need to distinguish more properly between error and really strong signal. Without considering the Cellular and Core RSSI reporting scheme, we should bound anything stronger than -1 dB to -1 dB.

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Jan 20, 2017

What would be the reference for dB calculation then? 20dBm = 100mW sounds like a good candidate for 2.4ghz wireless, or do we want to report dBW?

Core is also currently reporting dBm but clamped to 0dBm.

Perhaps we should think of uniforming .RSSI()? Electron could report dBm as well, since 0-31 levels reported by AT+CSQ are tied to dBm. And we could have a separate method that would tell signal strength as a ratio to some reference either in dB or as a percentage.

@technobly

This comment has been minimized.

Copy link
Member Author

commented Jan 20, 2017

I don't think we should label it dBm even though it might be intended as such, since a customer might not use the on board or recommended antenna. RSSI is also not supposed to be used as an absolute measurement, but more of a relative one based on the MFG's initial calibration.

RSSI

There is no standardized relationship of any particular physical parameter to the RSSI reading. The 802.11 standard does not define any relationship between RSSI value and power level in mW or dBm. Vendors and chipset makers provide their own accuracy, granularity, and range for the actual power (measured as mW or dBm) and their range of RSSI values (from 0 to RSSI_Max)

We just spit out unit-less dB value, but docs can add more meaning to the values. Electron docs say

rssi: (int) is the signal strength with range -113dBm to -51dBm (in 2dBm steps)

I do see that the WICED SDK does seem to indicate power is in dBm, but not exactly clear that RSSI is reported that way, and it doesn't give a range. There is a note in one spot that 0 for rssi not found (caller could retry)

Where did you find that the CC3000 reports RSSI in dBm?

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Jan 20, 2017

How would dBm value (which is milliwatts) be affected by antenna? The dBm reported is the actual signal power that the receiver sees at its input.

There is no range provided in WICED, but we could assume it's somewhere within -100dBm and 20dBm :)

I did some googling on CC3000 and ended up on TI forums. CC3000 returns a 7-bit dBm value offset by +127. See https://github.com/spark/firmware/blob/60f703bd4165a292f89124a7e3755e4eb37b1a03/hal/src/core/wlan_hal.c#L182

How about we report dB in all .RSSI() methods and provide additional methods to get dBm and reference dBm?

@technobly

This comment has been minimized.

Copy link
Member Author

commented Jan 20, 2017

Well yes the value would be that reported by the radio, but there may be other losses involved due to antenna and cable chosen, and placement. So the actual signal present at that location may be reported inaccurately due to those factors. I think most people would use this number as a relative strength of signal -90 being weak and -30 being strong... anything outside that range is just weaker or stronger. There is a place for real units, but I think that's probably best reserved for lab testing.

If we have data though that suggests dBm (like electron), we can put it in the docs. I don't think we need a different method for dB and dBm since they will have the same numbers. dB is just a ratio of measured power to a reference power. If we know for sure that the module we're reporting RSSI for was based on a 1mW reference power, then we can just say 0 dBm = 1mW and -80 dBm = 10 pW. If we don't know the reference, then it's still a 0 dB to -80 dB range in relative RSSI levels.

I think we should simply truncate the positive values and document in Docs what we know as facts about what these numbers represent. I don't think it matters much to say the level is 0 either, since that is the supposed max signal as originally calibrated. To see 1mW of power received, you must be right on top of the AP's antenna. If you are that close to your AP you can couple noise into other parts of your circuitry which could cause undesirable effects. Our reported range of -127 to -1 works well.

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Jul 7, 2017

Fixed in #1271, released in 0.7.0-rc.1

@avtolstoy avtolstoy closed this Jul 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.