Eddystone problems

RE: Eddystone problems

Einar Thorsrud — Mon, 17 Aug 2020 14:06:45 GMT

Then you must change the advertising data so that it is a valid Eddystone packet. I do not have any reference code for that (as mentioned the Eddystone example is much more complex than just a simple static beacon), but you can refer to the Eddystone specification, for instance for the UID frame that I linked to in a previous post.

RE: Eddystone problems

Roei — Mon, 17 Aug 2020 14:04:21 GMT

OK, now I can recognize that as a Beacon, using nRF Connect, thanks!

However, how can I recognize it as an Eddystone, using NRF Beacon for Eddystone?

Just change some configuration?

RE: Eddystone problems

Einar Thorsrud — Mon, 17 Aug 2020 13:56:48 GMT

I see. Then you should be able to see the advertisements using e.g. nRF Connect, but it still will not be recognized ad iBeacon unless you change to Apple's company identifier.

RE: Eddystone problems

Roei — Mon, 17 Aug 2020 12:58:47 GMT

No, I'm using a Galaxy

RE: Eddystone problems

Einar Thorsrud — Mon, 17 Aug 2020 12:40:26 GMT

Are you using an iPhone? If so, you need to change the company identifier to Apple in order for the iBeacon to show up on an iPhone. To do that, just set APP_COMPANY_IDENTIFIER to 0x004C (Apple) instead of 0x0059 (Nordic).

RE: Eddystone problems

Roei — Mon, 17 Aug 2020 12:31:03 GMT

Thanks! I will check that.

Another thing, is that my device can't send any beacon packets (NRF52840 - using iBeacon example).

I'm using NRF beacons app and can't recognize any beacon.

Is there any known issue?

RE: Eddystone problems

Einar Thorsrud — Mon, 17 Aug 2020 12:25:44 GMT

It just depends on the content of the advertisement packet, which you generate yourself. I suggest you refer to the iBeacon example to see how you can hand-write an advertisement packet payload, and then refer to the Eddystone specification. For instance here for a Eddystone-UID frame, if that is what you need(?).

RE: Eddystone problems

Roei — Thu, 13 Aug 2020 14:23:10 GMT

OK,

So everything depends on advertising parameters?

I didn't see any special advertising parameters in Eddystone example.

RE: Eddystone problems

Einar Thorsrud — Thu, 13 Aug 2020 13:48:42 GMT

Whether it is iBeacon or Eddystone is not really relevant if all you want is a simple non-connectable fixed content beacon packet, it is just that the advertising data would be different. Everything in the post I linked to is equally valid in both cases.

RE: Eddystone problems

Roei — Thu, 13 Aug 2020 13:46:39 GMT

Hi,

I've noticed that this post is about iBeacon, while I need an Eddystone format. Is that possible?

RE: Eddystone problems

Einar Thorsrud — Thu, 13 Aug 2020 13:38:15 GMT

Hi,

I see. You can refer to this post, which describes a way to implement this. The post is slightly old, but still valid today.

RE: Eddystone problems

Roei — Thu, 13 Aug 2020 12:39:25 GMT

Hi, thanks you for your quick response!

I need a simple fixed advertisement packet of Eddystone, which will be recognizable by NRF beacon for Eddystone, for example.

As I already have an infrastructure for advertisement with and without whitelist, I need to advertise in beacon format for a few seconds before my application starts the regular advertisment.

I guess it's just about configuration. But I need some help with that - how can I configure an advertisement of Eddystone, and after that - configure it back to the previous?

Thanks!

RE: Eddystone problems

Einar Thorsrud — Thu, 13 Aug 2020 12:11:08 GMT

Hi,

A full Eddystone beacon is quite complex, and the Eddystone example in the SDK is intended to be used as-is (more like a reference design). Referring to this post I wonder if you need a full Eddystone beacon? Or do would you be happy with a simple beacon similar to iBeacon?

If by the most basic Eddystone you mean just a fixed advertisement packet (just a iBeacon, but with a different format), then you could achieve this by regularly (using an app_timer for instance) reconfiguring the advertiser, switching from connectable advertising with whitelisting etc. to the beacon advertising, and then back again. Doing to in quick succession would make it seem like you are concurrently advertising both types of packets.