[TLM] Battery voltage, 1 mV/bit description could be more clear.

[skwasniak]

The description of the field VBATT could me more clear by rephrasing it in the following way:

"Battery voltage is the current battery charge in millivolts, expressed with 1mV resolution."

Same applies for the table of fields.

Additionally I would suggest to express battery level in [%] instead of volts.

I believe the main purpose of this field is to warn the maintainer of the beacon that it is running out of energy, and voltage measurements do not contain such an information. I can easily imagine beacons on the car with power supply ranging from 5V to 15V, yet another one using USB 4.25V to 5V supply, another one using lower voltages 1.8V to 5V.

Now imagine maintainer gets packet stating that VDD of some beacon is 5V. Does this mean that the energy storage is full or empty, without not knowing technical details of the device.

[mashbridge]

the goal of the telemetry is that it's observed over time, not as a one-shot report. knowing your beacon is at 5V is interesting, but repeated sightings over multiple days will allow an analytics system to forecast the decay.

[skwasniak]

Hi,

thanks for the quick replay.

So you are assuming that beacons constantly/periodically are sending telemetry packets to the cloud?

I think this is a false assumption - imagine URL beacons (from different vendors with different power supply types) in the national park spread on the large area. To keep the infrastructure running you need telemetry packets (in the end once a year maintainer will come to this park to replace batteries that are on a low level). Fulfilling your requirements will drastically increase the infrastructure cost as you will need some sort of a line powered gateway next to each beacon (2.4GHz range is very limited) which pretty much kills the whole concept of beacons.

Not using telemetry packets at all will mean that the maintainer will have to access every beacon (some can be placed even on masts/trees), measure manually battery level and make a decision to replace the battery or not. This would skyrocket maintain costs on the other hand.

To be honest, I've started whole discussion because I'm developing now solar powered beacons which actually have capacitor instead of battery, and telemetry would be useful during installation process. Installer will place beacons in the desired places. Come in a day or two and check if the beacons' energy storage level is high enough.

P.S.: This discussion above is a little bit an offtopic. What about the wording in the description of the field?

[mashbridge]

Passive collection. The beacons just beacon; other devices (e.g. Android phones) periodically scan for BLE signals around them and report that information to the cloud: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beaconinfo/getforobserved https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beaconinfo/getforobserved#Observation

And then the owner of the beacons can check the overall stats of the fleet: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons.diagnostics/list

[skwasniak]

Yes, passive collection makes sense but three questions are coming to my mind then:

1. Will Encrypted TLM be passed by any observer to the cloud and decrypted there?
2. How can you protect Unencrypted Data from the man in the middle attack that triggers LOW_BATTERY alarm.
3. How do you set LOW_BATTERY alarm? I don't see an option for that when adding beacon via "Beacon Tools" app nor beacon dashboard.