• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 52 subscribers
  • Views 556 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837 low BLE RSSI levels

user5843968
Prodigy 40 points
Other Parts Discussed in Thread: WL1837, WL1837MOD

we connect sensor packs to Linux edge gateways over BLE, we experience issues with devices that have a WL1837 controller. this is confirmed for 3 completely different devices - a SBC from Compulab, a Moxa industrial computer and a Eurotech edge gateway. we compare it to Parani UD-100 USB controller (a CSR chipset).

the most obvious thing that we see is much lower RSSI levels with devices that are located right next to each other and the exact same distances, we also use the exact same antennas, e.g. -87 @ WL1837 vs. -63 @ UD-100. I thought that it might be only a difference in the readings but in a bit longer distances the WL1837 is unusable while the UD-100 is completely fine. this repeats for any device that we try with WL1837.

all devices that we tried are using the latest .BTS file from the Bluetooth service pack. we're using Bluez 5.50 and kernels 3.14, 4.4 and 4.9

we're frustrated from this and I'd like to get any kind of insights about the BLE performance of WL1837

  • 0
    TI__Mastermind 29291 points

    Could you please provide more information regarding your hardware that has WL1837 on it?

    - Is it a chip-down design? Or does your board use the TI WL1837MOD?

    - Have you characterized the RF performance (e.g. TX output power and RX sensitivity tests) of the WL1837 on your board? Does it match with the datasheet specifications?

  • 0 in reply to user5843968
    TI__Genius 12730 points

    Hi,

    I hope all is well. If I understand you correctly you are stating that the 3 products using the WL1837MOD above have the same performance compared to the UD-100 correct?

    Looking at the spec for the UD-100. This is rated as Class 1 (https://adaptivemodules.com/usb/parani-ud100-bluetooth-usb-adapter/). The output power is + 19dBm EIRP. Our device is not cable of the 19dBm and is limited to 7dBm. So it this case when you are further away the higher power will help. The higher RSSI seen on the UD-100 would make sense based on the higher gain in this case. The additional difference could also be due to simply moving the antenna and not having it matched properly or having the 2 devices not aligned thus not providing max power transfer.

    I hope this helps.

    Thanks,

    Riz

  • 0 in reply to Rizwan Murji
    Prodigy 40 points

    we have other issues the appear as random disconnections and loss of sync of our datagram protocol over GATT when multiple peripherals are connected,

    we don't experience issues with other controllers like Intel or the UD-100.

    it is very hard to debug, definitely over forums. my question is - are there any issues, things to know or best practices while using this module extensively in high-performance applications (transferring a relatively large amount of data, from multiple peripherals) with BlueZ?

  • 0 in reply to user5843968
    TI__Mastermind 29291 points

    Hi,

    The WL1837 is a WLAN+BT+BLE combo device that has built in coexistence between these protocols. The priority of a BLE connection is dynamically selected based on other processes (e.g. BT conenction or WLAN beaconing etc.) running at the same time. So when looking at high-performance application like transferring relatively large amount of data over multiple BLE connections, the stability and throughput of the data transfer will depend on all the other processes running over classic BT and WLAN. It will not be a fair comparison when looking at other controllers that only support BT+BLE or BLE only technology. 

    However, there are some steps that you can take to decrease the unnecessary load on the WL1837, if the application allows. 

    e.g. 

    1. Disable WLAN

    2. Turn off page and inquiry scans on the classic BT

    Please note that WL1837 can support connections to 10 peripherals at max as mentioned in the datasheet. If the connection interval with these peripherals are aggressive and the RF environment is less than ideal, this number would be lower.

  • 0 in reply to Vihang Parmar
    Prodigy 40 points

    we need WLAM but we don't use classic BT, will turning off page and inquiry scans help? how can this be done in Linux/Bluez?

    with 7.5ms connection interval we see issues (connection drops) if we connect to more than 3 peripherals, does this number make sense?

    is it possible to control the BLE tx power from Linux/Bluez and make sure it's at the maximum?

    we have another device that has this module - https://www.jorjin.com/product.php?id=99

    in the datasheet they mention +12.5dbm tx power in BLE, does it make sense?

  • 0 in reply to user5843968
    TI__Mastermind 29291 points

    Hi,

    user5843968 said:
    how can this be done in Linux/Bluez?

    We are by no means experts in BlueZ implementations since only the TI dual-mode BT stack is supported on these forums. However, I found this relevant documentation about BlueZ from a quick google search.

    https://www.systutorials.com/docs/linux/man/8-hciconfig/

    Please refer to the "noscan" command on this page. It is supposed to disable both page and inquiry scans for classic BT.

    user5843968 said:
    is it possible to control the BLE tx power from Linux/Bluez and make sure it's at the maximum?

    The device is configured to use the highest BLE power level by default. So as long as you are not explicitly lowering the output power from your application, you can assume it is operating at the highest power level.

    user5843968 said:
    in the datasheet they mention +12.5dbm tx power in BLE, does it make sense?

    Yes, it makes sense. All the module datasheets specify the maximum output power at the module's input. Depending on the module's internal design, there can be band-pass filter and or switch in the RF path (inside the module) between the WL183x IC's RF pin and the module's RF pin. Since every module design (e.g. TI branded module v/s Jorjin module) will have different filter and switch components, it makes sense the loss in the path will be different between modules. Hence' slight different in the output power specification at the module level. 

    Best regards,

    Vihang