Feature inquiry: TPMS

[L3m0nk]

Hey super happy you dropped this. I've been working on a similar app, but due to time haven't had a chance to finish it. This is far more refined!

I haven't reviewed your code yet, however, is the scanning lib your using capable of scanning for low power BLE TPMS sensors? Sometimes they're hidden/unnamed and only visible on deep scans.
This would give the tool to detect most newer following vehicles with functioning TPMS sensors. It may require TPMS specific detection logic though.

I would also suggest additional filters, such as maybe RSSI thresholds. Also a setting to detect via GPS or accelerometer when on the road and only scan when mobile may be useful.

[Semper-Viventem]

Hey, thank you for your feedback! Those are awesome ideas about road mode, I think it may be helpful.

Regarding TPMS and BLE library, I use the standard android framework's mechanism working with BLE, I'm not sure if there is only one standard for TPMS communication. If some of these sensors work with BLE so it may be possible to detect this.

[L3m0nk]

Some of the specific identifiers for TPMS/tire pressure are in this: https://www.bluetooth.com/specifications/assigned-numbers/

Categorizing/filtering by some of these could be useful - unsure if this is different from manufacturer id though.

Another valuable feature for the road mode/filters are inclusion/exclusion radiuses on the map like IFTTT

[L3m0nk]

Accidental close

[L3m0nk]

doing some testing: two other questions:
Are you using CALLBACK_TYPE_ALL_MATCHES?
Also what type of SCAN MODE - low latency or balanced?

Thanks and great work!

[Semper-Viventem]

Are you using CALLBACK_TYPE_ALL_MATCHES?

The app process all BLE data, I don't segregate it by the callbackType. Shall I?

Also what type of SCAN MODE - low latency or balanced?

I use SCAN_MODE_LOW_LATENCY because it gives us more realistic data. Android has a lot of restrictions for background scanning so it is good to improve accuracy in anyways

[L3m0nk]

By default, if you don't specify a callbackType, Android's BLE API will use CALLBACK_TYPE_FIRST_MATCH. This means that the API will stop scanning as soon as it finds the first matching device, and won't continue scanning for other devices.

On the other hand, if you specify CALLBACK_TYPE_ALL_MATCHES, the API will deliver a callback for every advertisement packet received from all scanned devices, regardless of whether the device has already been seen before. This means that you will get more frequent callbacks and potentially more data, which could result in a larger number of visible devices.

Thoughts?

[L3m0nk]

May be effective, as our goal isn't to successfully connect, but just identify existence and proximity.

Also, I see mention of the other reported 'bug" that devices aren't visible - this may be related.