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

ble_sensed_mode in the data model #1068

Open
JGreenlee opened this issue Apr 22, 2024 · 1 comment
Open

ble_sensed_mode in the data model #1068

JGreenlee opened this issue Apr 22, 2024 · 1 comment

Comments

@JGreenlee
Copy link

JGreenlee commented Apr 22, 2024

Since last week, we have a basic working demo for bluetooth integration. The native code records BLE scans as background_bluetooth_ble entries. The phone reads these entries and matches them to composite trips according to timestamp. Essentially, we treat the ble scans the same as unprocessed user inputs.
The matched beacon is the one that had the most RANGE_UPDATE entries during the timestamps of the trip. This works for now, but we will want something more robust moving forward.

I think we want to implement matching on the server with respect to sections rather than entire trips.
The analysis/*section objects already have a sensed_mode property. I think they should also have ble_sensed_mode where the value is the beacon's major:minor in hexadecimal as a string (e.g. "dfc0:fff0")

analysis/confirmed_trip objects should have new properties for primary_sensed_mode and primary_ble_sensed_mode. (The primary section is the one with the greatest distance, correct?)
In #1062 (comment), we also spoke of having ble_sensed_section_summary, similar to the current inferred_section_summary and cleaned_section_summary.

I think we should also have a summary of the values in the confirmed and composite trips, similar to the current inferred_section_summary and cleaned_section_summary to make it easier to find the primary mode instead of having to iterate over the sections. This could be called ble_sensed_section_summary and the keys would be the baseMode

I want to make sure I understand what this would look like. The existing summaries have a structure of:

{
  count: {
    <baseMode>: number,
  },
  distance: {
    <baseMode>: number,
  },
  duration: {
    <baseMode>: number,
  },
}

To create the ble_sensed_section_summary, we will need to look up the baseMode in the dynamic config using the primary_ble_sensed_mode. Is that right?

@JGreenlee JGreenlee moved this to Questions for Shankari in OpenPATH Tasks Overview Apr 22, 2024
@shankari
Copy link
Contributor

shankari commented Apr 26, 2024

analysis/confirmed_trip objects should have new properties for primary_sensed_mode and primary_ble_sensed_mode. (The primary section is the one with the greatest distance, correct?)

Yes

https://github.com/e-mission/em-public-dashboard/blob/134cd25722f1e1ebaa566e8ffb45f3d8d497e1fd/viz_scripts/scaffolding.py#L227

To create the ble_sensed_section_summary, we will need to look up the baseMode in the dynamic config using the primary_ble_sensed_mode. Is that right?

No. we will create a ble_sensed_mode for each section (similar to the current sensed mode).
we will then expand get_section_summary to generate ble_sensed_summary similar to the existing cleaned_section_summary
finally, we will generate the primary_ble_sensed_mode from the ble_sensed_summary. Note that we will do so on the client instead of adding this new field to the data model.

@shankari shankari moved this from Questions for Shankari to Issues being worked on in OpenPATH Tasks Overview Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Issues being worked on
Development

No branches or pull requests

2 participants