You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?)
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.
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 asensed_mode
property. I think they should also haveble_sensed_mode
where the value is the beacon'smajor:minor
in hexadecimal as a string (e.g."dfc0:fff0"
)analysis/confirmed_trip
objects should have new properties forprimary_sensed_mode
andprimary_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 currentinferred_section_summary
andcleaned_section_summary
.I want to make sure I understand what this would look like. The existing summaries have a structure of:
To create the
ble_sensed_section_summary
, we will need to look up thebaseMode
in the dynamic config using theprimary_ble_sensed_mode
. Is that right?The text was updated successfully, but these errors were encountered: