-
Notifications
You must be signed in to change notification settings - Fork 34
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
Determine what bluetooth signals vehicles give off and how they can be read while in the foreground and background #1046
Comments
Initial FindingsI've been diving head first into Bluetooth research; here's some notes and thoughts on what I've found so far! A Note on Key Fobs
Bluetooth v.s. Bluetooth Low-Energy (BLE)
Sample Bluetooth Meter Apps
†The docs for BleCORE are in Mandarin -- from what I can gather, their demo app does what we want to test (just in Kotlin). If we want to look into this further, I've got a friend that could help me read through the docs! Final NotesI'll keep adding to the table above as I find more example apps -- if anyone's familiar with some, please let me know! As the table shows, there doesn't seem to be a "one-size fits all" example project that we could use as a code reference. I may start with a desktop BLE scanner on my personal computer, just to test my stereo-broadcast hypothesis -- once I've got more data, I'll make another post on this thread! |
Couple of high-level thoughts:
Yes, cordova has plugins for lots of things - some cordova app developers have never written native code - only javascript, and will not implement functionality if they have to drop down to native. We can definitely reuse code from it, but I don't think we will want to use it as a plugin directly because plugins are intended to be called from javascript, and we want to call the bluetooth from the FSM that is implemented in native code |
Making a Bluetooth Test ScannerJust putting some initial thoughts on the project here! The goal is to make a very simiple app that allows us to see a list of all currently broadcasting Bluetooth devices within capture distance. Since our research revealed that there isn't a "one-size fits all" app, the plan is to make a simple one ourselves. Admittedly, we could use a selection of the apps detailed above, but I think this will be a helpful learning exercise! I'm thinking we make this app in React + Cordova, since it's what we're already using. Task Brainstorm
What's NextLouis and I are meeting tomorrow to discuss these rough plans -- we'll find a way to divvy up the task, and update this thread with our progress! |
@the-bay-kay @louisg1337 I wanted to suggest that instead of building a new app and setting up the toolchain all over again, you can just change the existing app. My suggestion would be:
That way, when people install the "GSA configured" app on their test phones, they can also test out the bluetooth without having to recompile. Thoughts? |
I think this is a great idea!! I spent some time chatting with Louis yesterday about designing an app from the ground up, but having the scanner hidden under the dev options would be far easier to implement. Plus, it'd make the distribution of the scanner way easier -- we'll pivot to making it an addition! |
See Issue [e-mission#1046](e-mission/e-mission-docs#1046 (comment)) for more details. This commit adds the Dev-Zone settings option, which will eventually link to the Bluetooth Scanner page. TODO: - Add i18next translation for control.bluetooth
Update on Plugin SearchWhen working on PR 1128, we've looked into a few other Bluetooth plugins and resources. Below is an updated table, along with some additional notes / resources. Most notably, Louis found a fork of the Bluetooth Serial Plugin that theoretically supports iOS Bluetooth scanning. There are, however, a few caveats:
According to these docs, it appears that iOS devices cannot scan for unrecognized Bluetooth devices in the background. I believe this means that we will be able to scan in the foreground, but I need to do further reading on the iOS Bluetooth docs (link) to determine how viable this approach is. As of writing, we are using the original plugin (link) in PR 1128 . I'll update this thread further when we test the fork that enables iOS bluetooth classic scanning! Bluetooth Scanning Plugins
|
BLE Beacon CandidatesBelow is a list of different BLE beacons that we can use for this project.
I'll add more to the list once I get more information from each company, and if I find any other good candidates. |
Current decision:
|
For the FSM changes, I think we can handle it in two approaches, and we may even need both to be safe.
Implement (2a), check power and accuracy, decide whether we need the complexity of (2b) Both of the above are for trip start which is the crucial part because we should not be tracking non-fleet trips, that is our promise. But we should document how to handle trip end for the record.
|
Plugin updates!@louisg1337 did some digging on our preexisting list of plugins, and found that the cordova-plugin-ble-central seems to be (i) the most popular BLE plugin, and (ii) the most frequently forked plugin. Within this plugin, however, they have a note:
Following their suggestions, we're looking to add this plugin in our second iteration of the developer Bluetooth scanner! |
In the long term, we will hopefully not need this permission since we will not be using the plugin. I'm going to try to remove the COARSE permission (we already have FINE) and then rebuild just so I don't add a new, spurious permission that I don't know how to remove when it is no longer necessary. |
BLE FLEET TestingThese tests are focused on testing the changes implemented within this branch of the Testing ProcedureTesting procedure will closely follow the simulated tests done by @shankari in PR 1144, but performed with actual beacons. The following will be my testing procedure: Test Setup
Beacon Setup & Usage.For tests involving the FLEET deployments of OpenPATH, I will be testing with a BLE Beacon.
Test Procedure
Goals for Data Collection:As described above, we are looking to analyze the the behavior of the trip tracking. I will provide the relevant segment of logs with each trip, and provide testing notes on the logs. With these test guides in mind, my first test will be with a 2022 iPhone SE, and I will report them within this thread. My additional tests will be performed on an iPhone 8, LGv30, and Nexus 6. Testing Setup Photos:Repository Set Up(TODO: Link to relevant PRs for documentation's sake) |
This is flipped. A visit is time spent at a place. So visit start = trip end and vice versa
This will work for iOS only. For android, @louisg1337 has set up the code so that the geofence is still primary, and only after the geofence exit, we start ranging to find the beacon. So on android, you will need to start a trip (using "Start trip") and then move the beacon near/far. Also, on android, the trip end is still based on the location based trip end, so geofence based exit is not meaningful.
I am not sure you can log in naively via fleet code - @JGreenlee's PR turning on the fleet tracking is still in draft and has not been merged. You will need to use a local server that is serving up configs. If you have not done this before, this is non-trivial. @JGreenlee, can I merge the PR so that @the-bay-kay can use the DFC fermata opcodes without having to set up the local config server?
You will also need to replace the usercache plugin. I have merged that and created a new release |
Thanks for the clarification! Updated the procedures.
Ah, correct -- thank you for the reminder! Updated accordingly, LMK if I understood the Android version correctly.
I have not done this before. You are referring to this PR, correct? Given I have some spare time this evening, I'll do my best to familiarize myself with the server testing procedure to see if I can't spin it up with a custom config. |
I don't think this will be easy. It is not the e-mission server, it is a server for the config. I would rather just merge the config and then fix it later as we get more information about cars than waste your time figuring that out. |
I don't think this is a useful test. Note that on android, "the trip end is still based on the location based trip end, so geofence based exit is not meaningful."
Means that there is no difference between fleet and non-fleet behavior. When you exit the geofence, location tracking will start. Instead, you should have:
on Android, there are no visit transitions, so you must use start and end trip transitions. |
@the-bay-kay that's very promising! we need to confirm a few details:
Once that is confirmed, you just need to do the same on android, and I can generate a staging release! |
Yes e-mission/nrel-openpath-deploy-configs#89 can be merged |
@the-bay-kay the fermata config has now been updated, so you should be able to just use a fermata opcode |
Ah, perhaps I misunderstood -- that was my plan originally, I may have been unclear in the way I wrote it. Those steps were what I had planned for both OSs -- LMK if I'm mistaken, and should do something differently for iOS. Either way, I'll update the Android side of the protocol now.
Will do! I'm getting the Android version set up, I'll:
|
Just to re-clarify, there are two axes to this: the proximity of the BLE to the phone, and whether the phone has received a geofence exit. On android, only the case of geofence exit -> BLE proximity should start tracking In your test case above, you are only testing geofence -> BLE proximity, which is fine for putting this on to staging. But once we put it on to staging and want to test more, we should also test having the beacon near the phone without the forced transition. This should (currently) start tracking on iOS but not on android. |
Ah, yes! Thank you for the clarification. Android on deck and the iOS / Beacon set up, running the next round of tests now. |
Android Staging Tests: LGv30With the changes merged into staging, my tests are performed with that installation, rather than through the build chain described above. Below are my initial findings: Non-Fleet Config:Simulating a trip as described above, 04-15 09:30:37.876 24044 26049 D LocationChangeIntentService: After filtering at -1.0 number of points goes from 9 -> 9
04-15 09:30:37.876 24044 26049 D LocationChangeIntentService: After filtering at -1.0 number of points goes from 9 -> 9
04-15 09:30:37.876 24044 26049 D LocationChangeIntentService: last10Points.length = 9
04-15 09:30:37.876 24044 26049 D LocationChangeIntentService: points5MinsAgo.length = 9
04-15 09:30:37.876 24044 26049 I LocationChangeIntentService: last10Points.length = 9 points5MinsAgo.length = 9 points, not enough to decide, returning false Fleet Config:These tests were conducted as described in the above posts. Within these tests, I noticed two beacons being frequently ranged, yet not recorded:
Using a BLE monitoring app (The iBKS config tool), it appears that neither of these beacons are actually within range. This seems exceptionally strange -- I cannot find any reference to these UUIDs within our code either. Any insight into these erroneous beacons would be helpful Luckily, it appears that these beacons do not get stored into No Beacon within RangeWithout the beacons in range, this is what the majority of the logs look like (e.g., ignoring user interaction logs such as 04-15 09:52:04.647 24044 24044 D BluetoothService: Range notifier called...
04-15 09:52:04.647 24044 24044 D BluetoothService: Found beacons [id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737]
04-15 09:52:05.753 24044 24044 D BluetoothService: Range notifier called...
04-15 09:52:05.754 24044 24044 D BluetoothService: Found beacons [id1: 74278bda-b644-4520-8f0c-720eaf059935 id2: 0 id3: 62946, id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737]
04-15 09:52:06.862 24044 24044 D BluetoothService: Range notifier called...
04-15 09:52:06.863 24044 24044 D BluetoothService: Found beacons [id1: 74278bda-b644-4520-8f0c-720eaf059935 id2: 0 id3: 62946, id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737] Logs after beacon enters range:It appears that we are successfully detecting the beacon 04-15 09:55:39.981 24044 24044 D BluetoothService: Found beacons [id1: 74278bda-b644-4520-8f0c-720eaf059935 id2: 0 id3: 62946, id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737, id1: bf3df3b1-6e46-35fa-86e5-927c95dd096c id2: 57280 id3: 1972]
04-15 09:55:39.984 24044 24044 D BuiltinUserCache: Added value for key background/bluetooth_ble at time 1.713200139983E9
04-15 09:55:41.090 24044 24044 D BluetoothService: Range notifier called...
04-15 09:55:41.091 24044 24044 D BluetoothService: Found beacons [id1: 74278bda-b644-4520-8f0c-720eaf059935 id2: 0 id3: 62946, id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737, id1: bf3df3b1-6e46-35fa-86e5-927c95dd096c id2: 57280 id3: 1972]
04-15 09:55:41.094 24044 24044 D BuiltinUserCache: Added value for key background/bluetooth_ble at time 1.713200141093E9
04-15 09:55:42.202 24044 24044 D BluetoothService: Range notifier called...
04-15 09:55:42.203 24044 24044 D BluetoothService: Found beacons [id1: 74278bda-b644-4520-8f0c-720eaf059935 id2: 0 id3: 62946, id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737, id1: bf3df3b1-6e46-35fa-86e5-927c95dd096c id2: 57280 id3: 1972]
04-15 09:55:42.208 24044 24044 D BuiltinUserCache: Added value for key background/bluetooth_ble at time 1.713200142206E9
04-15 09:55:43.314 24044 24044 D BluetoothService: Range notifier called... |
Android TestsI ran two tests, both on the staging version of the app.
|
This is concerning. I thought you said that with the foreground service, the ranging does work and you were able to see trips on dfc-fermata before. Is the foreground service not running properly any more? |
When moving the app to the background, these are the logs I'm getting (with activity pausing with 04-15 10:29:15.870 24044 24044 D BluetoothService: Found beacons [id1: 50765cb7-d9ea-4e21-99a4-fa879613a492 id2: 54006 id3: 53737]
04-15 10:29:16.583 24044 24044 I ScanJob : Using immediateScanJobId from manifest: 208352939
04-15 10:29:16.584 24044 24044 I ScanJob : Using periodicScanJobId from manifest: 208352940
04-15 10:29:16.584 24044 24044 W JobInfo : Requested interval +5m10s0ms for job 208352940 is too small; raising to +15m0s0ms
04-15 10:29:16.584 24044 24044 W JobInfo : Requested flex 0 for job 208352940 is too small; raising to +5m0s0ms
04-15 10:29:16.606 24044 24044 D CordovaActivity: Paused the activity.
04-15 10:29:16.620 24044 24044 I ScanJob : Using periodicScanJobId from manifest: 208352940
04-15 10:29:16.620 24044 24044 I ScanJob : onStopJob called for immediate scan org.altbeacon.beacon.service.ScanJob@9bd1542
04-15 10:29:16.620 24044 24044 I ScanJob : ScanJob Lifecycle STOP: org.altbeacon.beacon.service.ScanJob@9bd1542
04-15 10:29:16.623 24044 24044 D BluetoothAdapter: isLeEnabled(): ON
04-15 10:29:16.627 24044 32518 D BluetoothAdapter: isLeEnabled(): ON
04-15 10:29:16.627 24044 24044 D BluetoothService: Range notifier called...
04-15 10:29:16.634 24044 24044 D BluetoothAdapter: isLeEnabled(): ON
04-15 10:29:16.635 24044 32518 D BluetoothAdapter: isLeEnabled(): ON
04-15 10:29:16.638 24044 32518 D BluetoothLeScanner: could not find callback wrapper
04-15 10:29:16.671 24044 24044 D CordovaActivity: Stopped the activity. When the app is re-opened, |
I'm not sure, when I did my tests I would have the app closed, then trigger a broadcast using adb, and the ranging would come on. Whats weirder is that with the version that I worked on, it was actually tracking trips I had a bunch of trips that successfully tracked with my beacon. I'll look at all the changes again and see if I could find what could have caused this deviation.
Same thing happens here, right when I open the app back up it starts ranging again. |
Potential Issue I'm just going to put a bunch of potential issues that I think could have happened here. I'll keep on adding to the list as I find more things!
|
I can verify that I can reproduce this in the emulator
This also appears to be expected behavior https://stackoverflow.com/a/73970568 if the foreground service is not configured.
@louisg1337 I checked the code and my changes (e-mission/e-mission-data-collection@04e0a19) and I am not sure how this ever worked
appears to be substantially the same as what we had before
And I don't see anything marking the service as starting in the foreground. Maybe you made a local change that you tested but didn't commit/push? |
Although, for the record, it is not clear that we need to mark this as a foreground service. The entire e-mission app has one foreground service, and all the other services (FSM, location, motion activity etc) run just fine in the background. |
Android Testing UpdateI unfortunately sent us on a witch hunt because it seemed like the trip I took earlier didn't track/do anything. It turns out I just didn't wait long enough for the server to process my trip, as it eventually did appear, albeit after a little while. We also ran into the rabbit hole of why the beacon ranging logs did not appear in the |
Testing Android Background ScanningApp in background with beacon nearby Started geofence exit at 2:29, then immediately moved app to the background and locked phone. Reopened the app and emailed the logs at 2:32.
App in background with no beacon and then beacon In this test we wanted to see what would happen when you start a geofence exit with no beacons around, move the app into the background, and then bring beacons into range. It appears that the At 2:49 I exited the geofence and moved the app to the background. We do pick up a random beacon in the region, but that is not the deployment beacon we are using. Then at around 2:53 I move the beacon back in range and we start getting call backs from the
|
A better long-term fix may be the "intent strategy" outlined above. I have not looked into how to enable it, and am not convinced that this will fix anything (given that the app is already running with a foreground service, but it is worth exploring to see if it is better) |
The text was updated successfully, but these errors were encountered: