Telemetry broadcasting and receiving interval

LTE Beacons
1

Hello everyone,

I have some questions about the telemetry broadcasting of the beacons. I developed an own app to receive the telemetry broadcasting signal and save the data (rssi, motion data) in a file directly in the smartphone.

The question is I set the broadcasting interval to be 200ms for the beacons, but I found the time interval of data written to the file is about 1000ms. Isn’t the device supposed to be receiving the signal continuously and then write to file as the same frequency as the broadcasting signal? Or is there any method to reduce the interval between received data?

Thank you very much,

Jiannan

2

Hello @pink0721

I assume you are using our old SDK, in which the telemetry scanner was scanning for both telemetry frames (frame A, frame B) and for Estimote Connectivity packet (it contains the full beacon id, where frame A and B contains only half of this id). All those three frames had to be merged together before reporting it to you, in order to report the full data + full beacon identifier. As you can see, this depends heavily on broadcasting intervals of the three frames - this is why you are getting scans less frequently then expected.

Fortunately, the scanning telemetry scanning mechanism is much better in our new ProximitySDK. You can choose between three scanning modes:

  1. estimoteTelemetryFullScan() -> contains merged data from frame A and B, as well as full beacon id (that you can use for Estimote cloud communication).Will be less frequently reported than individual frames.
  2. estimoteTelemetryFrameAScan() -> data from frame A + short device id. Reported on every new frame A.
  3. estimoteTelemetryFrameBScan() -> data from frame B + short device id. Reported on every new frame B.

Here is how to start the full telemetry scan in the ProximitySDK:

 bluetoothScanner = EstimoteBluetoothScannerFactory(applicationContext).getSimpleScanner()
        telemetryFullScanHandler =
                bluetoothScanner
                        .estimoteTelemetryFullScan()
                        .withOnPacketFoundAction { Log.d("Full Telemetry", "Got Full Telemetry packet: $it") }
                        .withOnScanErrorAction { Log.e("Full Telemetry", "Full Full Telemetry scan failed: $it") }
                        .start()

You can see the spec of both telemetry frames here.
You can also read about how to use telemetry scanning to build awesome Android Things powered app.

Kind regards,
Paweł

1 Like
3

Even thou beacon is advertising every x ms, receiving device might not be able to receive all frames in the same pace due to:

  • radio interference
  • weak signal
  • radio noise
  • buffer overflows
  • Bluetooth radio rx/tx switching
  • system scheduling (Android is not a real-time OS)
    …and many more.
    Even when you build custom receiver with noise filters, amplifiers and real time OS it would not guarantee that all frames will get received (that will result withe the same speed of receiving and transmitting). That is the nature of radio waves.
2 Likes
4

Hello @paweldylag,

Thanks for the information. I checked the spec for telemetry and still have some questions.

  1. I understand that the frame A mainly contains motion related data and frame B contains other sensor data. But how can I get the rssi value? (assuming I only want to scan one frame to increase the frequency)

  2. With the new SDK, can I still create EstimoteTelemetry class and access the data by, for example, tlm.temperature like what we do using the old SDK? Or I need to parse the raw data by myself?

Thank you very much,

Jiannan

5

Hello @pober,

Thank you for pointing out the theory behind it. Now I can understand, and maybe I can at least increase the broadcasting frequency to get more data.

Jiannan

6

Hey

  1. The RSSI value is in the object returned by your scanner - for example packet.rssi
  2. Yes, all data is already parsed and is inside the object you receive. No need to write custom parsing :slight_smile:

Regards,
Paweł