RSSI can be positive

[dartasen]

To give a bit of context, In a .NET MAUI mobile app (Android/iOS) I'm constantly scanning BLE frames, which enables me to collect data from our sensors that emit BLE frames. During tests that can last from several minutes to a few hours, I've noticed that the library can provide a positive RSSI for some devices.

Setup

private static readonly ScanFilterOptions options = new()
{
     ManufacturerDataFilters = [new ManufacturerDataFilter(0x[REDACTED])]
};

IAdapter adapter = CrossBluetoothLE.Current.Adapter;
adapter.ScanMode = ScanMode.LowLatency;
adapter.ScanTimeout = 10000;
adapter.ScanMatchMode = ScanMatchMode.STICKY;
adapter.DeviceAdvertised += AdapterOnDeviceAdvertised;
adapter.ScanTimeoutElapsed += async (sender, e) =>
{
    if (!shouldScanDevice)
    {
        return;
    }

    await adapter.StartScanningForDevicesAsync(options);
};

Actual behavior

IDevice.Rssi can return Invalid RSSI values

Sometimes it seems that the value had overflow (128), but sometimes it seems that the manufacturer layer might be sending some specific code that the library mihght not yet understand

Configuration

Version of the Plugin: 3.1.0

Platform: e.g. iOS 13, iOS 15, Android 11, Android 13, Android 14, ...

Device: e.g. iPhone X, iPhone 12, Samsung S23, Samsung S20FE, Redmi Note

[smsissuechecker]

Hi @dartasen,

I'm the friendly issue checker. It seems like (37.50 %) you haven't used our issue template :cry: I think it is very frustrating for the repository owners, if you ignore them.

If you think it's fine to make an exception, just ignore this message. But if you think it was a mistake to delete the template, please close the issue and create a new one.

Thanks!

[axa88]

Are you sure that isnt the actual value being returned by the device? -128 is the defacto 'invalid value' used by some peripheral To which you could easily filter out.

[dartasen]

Are you sure that isnt the actual value being returned by the device? -128 is the defacto 'invalid value' used by some peripheral To which you could easily filter out.

I don't have -128, it's even worse you can get positive values (i.e: 117 and 120 dBm in my screenshot). It's pretty easy to filter out afterwards, that's not the issue

[axa88]

that's not the issue

ya. might not be your issue but this API is a thin wrapper. If you look at the source code there really isnt much opportunity for it to start randomly inverting numbers as you claim. It is far more likely that these are the values that were calculated as is. If you dig into it, you'll find that the value is sent directly from the radio to the OS Bluetooth stack, and it handles lots of data, so corrupting this one and only one byte seems unlikely.

Your best bet is start logging the id of these devices and perhaps you can identify one that is going off the rails somehow, or even perhaps find a bug in whatever that software is you're using to plot the graph?... cuz maybe im wrong but there isnt a bug in this API that can fix this.