Eddystone TLM Packet for Estimote Proximity Beacons Discovery (Filtering?)

LTE Beacons
1

Hi,

I have just started with using Estimote beacons have a quick query in regards to broadcasting Eddystone on proximity beacons.

I been looking into an application which reads the temperature sensor. Based on my understanding using the Estimote Default package the only way to do this would be to establish a connection and read the value, which is both power draining and also prevent the beacon broadcasting. The alternative is (beside moving to nearables or location beacons) is to set the beacon to broadcast a Eddystone package instead.

I have upgrade the beacon’s firmware to 3.2.0 and set it broadcast eddystone UID packets. Apologies ,if I am describing this wrong still getting my head around the lingo.

My question/issue is with how best read the telemetry packets. I looked over the various bits of documentation, api documentation and post I can find (it a little all over the place) to kind of work up a solution that somewhat works. So apologies if I may of missed something pointing me to the solution, I haven’t be able to find one). Using ESTEddystoneManager I am able discover the TLM packets however only if I discover with a nil filter, in which case I get both a UID and TLM packet (I know they are broadcasted separately).If I apply a ESTEddystoneFilterUID when start the discovery than I didDiscoverEddystones only returns non TLM packets. However there doesn’t appear to be any similar functionality for discovering just TLM packets. This is not a problem per se but it does seem to mean that I can’t do discovery for a particular beacon or a particular TLM packet without having to manually check through all the elements of [eddystones] returned by didDiscover. I am currently doing this via isKindOfClass(ESTEddyStoneTLM).

Also, what is the broadcasting rate on the TLM packets, I was under the impression that it was it was only broadcasted every few seconds. I however seem to be getting it every discovery.

Any assistance or direction would be greatly appreciated.

Using
Estimote Proximity beacons, revision D3.4, Firmware 3.2.0
Iphone 6plus

2

Welcome on board Aria (: Out of curiosity, how do you plan to use the temperature data from the Eddystone TLM packet?

Great feedback about lack of TLM filter, thanks for that! Agreed it’s quite inconvenient to have to do the filtering yourself.

Also, what is the broadcasting rate on the TLM packets

In Proximity Beacons, it’s 12 seconds. In our new Location Beacons, you can configure the interval and power of the TLM packet independently from the other packets.

Let us know how else we can help!

3

Thanks for the prompt reply.

In regard to the broadcast 12 seconds was what I thought but in my current implementation I seem to receiving a TLM packet overtime I receive a UID packet. That is with nil filter and one beacon I seem to receive a array of 2 eddy stones packet. Using isClassOf one matches a eddystoneTLM while the other matches UID. Which seems very strange to me. Is it just filling intermediate didDiscover with some kind of ghost data since the last proper TLM packet. Again not that I am overly worried just curious.

As for temperature data use there is nothing overly specific atm. I am just overly curious especially since they were surpringly a lot more sensitive than my initial preconceptions lead me to believe. I was suprised holding that when I clutched them in my hand that it detect a iterative increase in temperature over time. I would of thought the casing would of really limited it. At the current moment I just thrown one outside of my place and sensing it in the morning to figure out if it too cold and whether i should snooze my alarm for another 30 minutes (lovely Australian winter). However given the sensitivity I was just intrigued to play around learn it limitations. I figured might be able to throw them around the office and quickly deploy an ad-hoc temperature monitoring system (throughout a room). Though I realise it may be a little rough (lot) but think it could take significant differences :slight_smile: However non the less interesting to have a look into their limitations and what can be done with them as is.