I am checking some Bluetooth Beacon data from yesterday against what I noted about my proximity to another person with a Beacon.
The data shows that we were first in proximity at 11:37am (assuming time_record is in GMT) and last in proximity at 4:01pm – both of those times look about right. We were sitting next to each other for most of that time (less than 2 metres apart), as well as going out to lunch together when we would have been closer.
The Beacons transmit 3x per second, so why are there only 11 records for those 4.5 hours? Does it only create a new record when there is a change in RSSI? Or is the data downloaded summarised from raw data in a similar way?
Hi @atdutoit
The app captures one record for every 5 minutes. So you should’ve had around 50 records. If you only see 11 records, that is an indication that either the app was terminated for part of this time, or the battery saving settings of the phone prevented the app to work on a regular once-every-5-minute interval.
You can check the reports in the Participant History Report for more details on why exactly there is not enough record during this period.
Hope it helps
Hi–thanks, I’ve gotten into Kibana and started using it at last.
I did a Participant History Report for myself per your instructions here, looking for Event 600, but there weren’t any visible for the last 30 days, and this conflicts with the data from the CSV of Bluetooth Beacon data I got from the Sensor Data / Data Export page.
I did the same thing for the person I was in contact with, ID 13823, and got the same thing: no Event 600s for the last 30 days. Neither by using ctrl-f to look over all the Events, nor by filtering the Events to include only Event 600.
I also did a Data Quantity report for ID 13823 and from 9am to 3pm on 13 Aug there were 30-40 Bluetooth Beacon records per hour, then falling to 25 records from 3pm-4pm and only 4 records from 4pm-5pm. (I’m assuming here that the Data Quantity report chart time is in AEST).
However–I downloaded ID 13823’s Bluetooth Beacon data for the relevant time period (I took in 12-14 Aug to be on the safe side) and got a very nice result. There were 67 records, and they covered the right time period, i.e. ¬9:20am to ¬4:00pm. So–the low number of records I reported earlier was just an issue with my phone. And–I realised that I had Battery Saver on my phone turned on, so that may well have had something to do with it.
So I have now turned off Battery Saver on my phone, as of 11:30am AEST today, so later on today I will see what that does for the number of BB records I have. I’ve been near a number of people with Beacons since 10am, and one person since 8:30am, so that should tell us something. I’ll report back on it.
Sorry I should’ve been more clear. Event 600 (Beacon contact) is reported only if you have Proximity survey in your study. The app tracks the “sessions” only in that case. If you don’t have any proximity survey (which I believe is your case here), the app just captures the raw beacon data and does not convert them to session, and does not upload any Event 600.
Other than this, it seems other things are in order. Correct?
Oh, you mean a proximity-triggered survey? I don’t have those, no. So that would explain the lack of Event 600s.
And yes, it does seem that things are in order, other than that.
Would it be possible to make the recording rate adjustable, so it can be made more frequent? I think that 1 per 5 min might miss a fair bit of proximity / inferred social contact, e.g. people meeting briefly in the hall or the kitchen.
Is a session a record of duration of proximity? That would be the sort of data I need, and while I think that in principle it should be able to be derived from the raw data I am receiving, it seems likely that the 1 per 5 min sampling rate might compromise this data.
(Also, is there a limit to how many feature requests I can make before I get kicked off the forum?? 
)
It’s not possible to keep recording more frequent than 5 minutes. That’s the lowest value that allows the phone to still go to sleep and save power periodically. If we want to lower this number, we have to set it to 0, meaning the app continuously should scan for data, which would have noticeable impact on battery usage.
What can be done is to scan once every 5 minutes, but then when a connection is detected, continuously scan until the connection is departed. This gives a higher accuracy, but still may miss some short contacts.
A session (as reported by the Event 600, or used in proximity triggered survey), is when a certain is visited in continuous 5-minute scans. So if the app observes beacon X at time t1, t1 + 5m, t1 + 10m, t1 + 15m, and t1 + 20m, and then it’s not observed anymore, the app creates a session for it from t1 to t1 + 20m. It’s not very hard to calculate this from raw data, just as app does it, but at the moment, Ethica does not record this session data as part of the beacon data source.
Note that the app still uses the same “1 minute every 5 minute” model to calculate the sessions.
And, no, there is no limit on the number of posts/requests, but this might change soon 
!
Thanks Mohammad.
What can be done is to scan once every 5 minutes, but then when a connection is detected, continuously scan until the connection is departed. This gives a higher accuracy, but still may miss some short contacts.
I would like to have this in my study–how soon can we implement it? Do I need to do something?
Note that the app still uses the same “1 minute every 5 minute” model to calculate the sessions.
I’m a little confused about this. Does Ethica scan for Beacons:
- one time every 5 minutes, or
- for a whole 60 seconds every 5 minutes?
And just to confirm my understanding of Event 600 sessions: a session is calculated as a duration by simply subtracting the start time of the session from the end time of the session–yes?
And, no, there is no limit on the number of posts/requests, but this might change soon 
!
Oh, come on, I am just trying to help … ! 
I would like to have this in my study–how soon can we implement it? Do I need to do something?
Unfortunately, we currently don’t have this in our roadmap, but I was explaining that as a possibility. I would need to discuss it with the rest of the team to know how much time such implementation requires.
I’m a little confused about this. Does Ethica scan for Beacons:
- one time every 5 minutes, or
- for a whole 60 seconds every 5 minutes?
Ethica always scans for 1 minute every 5 minutes.
And just to confirm my understanding of Event 600 sessions: a session is calculated as a duration by simply subtracting the start time of the session from the end time of the session–yes?
Yes. A session is calculated by subtracting the time of the first visit from the time of the last visit. A visit is marked as the first visit if the beacon does not have an active session currently (i.e. it was not seen in the past 10 minutes). A visit is marked as the last visit if the beacon is not seen for 2 consecutive 5-minute intervals (i.e. 10 minutes).
Oh, come on, I am just trying to help … !
I’m kidding! 
Thanks for the further explanations.
And I am, of course, most interested in the possibility of triggered continuous scanning–please let me know if there is any movement on that front.
1 Like
)
!