Skip to main content

Location Frame

Comments

1 comment

  • Ferenc Bartók

    What use case do you propose for Location packet (what did you have in mind when creating it)? At first it sounds great for location calculation as you write but if you dig a bit deeper it really doesn't help for real time solutions. 

    Here is why:

    Even though Location packet is more accurate because it only uses one BLE channel (we can see why using all 3 channels can be bad here for example: https://stackoverflow.com/questions/49634513/is-there-an-explanation-for-the-regular-oscillation-experienced-in-bluetooth-rss ) it can be hardly detected by mobile phones because of SCAN_INTERVAL settings (on Android). The current official (lowest) SCAN_INTERVAL is 4096 ms (4 seconds!) which in a real time scenario doesn't help at all, maybe for some very big error checking but then something has already gone really wrong. (I know this INTERVAL setting can be different from mobile to mobile.) This means that we are not receiving location packets for 8 seconds, then receiving for 4 seconds (and this repeating). ( https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4327007/ 3.1 section). I've tested this and it's exactly what is happening (8 seconds of silence).

    If I'm mistaken please correct me! I'm really curious as to how one could really utilize Location packets for realtime location calculation (such as indoor postinioning). Or was it created for non/semi-real time use cases in mind?

    This comment should not in any way be understood in a negative way, for 1) I'd like to know if I understand things correctly, for 2) other people should see the not too obvious (but really important) limitations of Location packet.

    Best regards,

    Ferenc

    0

Please sign in to leave a comment.