|
This is a demo of using "Simblee For Mobile" as the configuration tool for a
Eddystone Beacon compatible with the Physical Web.
RFduino and Simblee do not provide access to create custom UUID characteristics,
which are required to configure a Eddystone URL over BLE. Using Simblee and
it's "Simblee For Moble" feature, the configuration APP can be stored on the
Beacon itself. Problem solved.
The following information is a work in progress and may be inacurate and/or inadequate. Beacons use BLE advertisement packets to broadcast their unique data. The Eddystone-URL beacon is simple in that all it sends is an URL that points to the owners website. (Actually any website, but it is not nice to point to something that is not your responsibility). An issue arises when the website URL is too big to fit in the limited space of an advertisement packet. The Eddystone-URL Beacon provides some compression ability by using a single byte to represent the type of URL (http:// or https:// or http://www. or https:/www. etc). It also uses a single byte for the TLD (Top Level Domain). Not all TLDs are covered yet, but the original ones are. (.com or .com/ or .edu or .edu/ or .org or .org/ or .edu or .edu/ or .gov or .gov/ plus a couple newer ones .biz or .biz/ or .info or .info/ ). This configuration tool can cycle through the supported domain types and TLDs. Any unsupported TLDs have to be entered as part of the domain name by clicking off the TLD chooser switch. The domain name itself and the site page path must fit in the available space. This tool displays how much space is available as the URL is built. Sites that have domain names and site page paths that are too big to fit in the available space have to use some kind of URL shortening service. This configuration tool does not do automatic URL shortening for those URL that are too big to fit in the limited advertisement packet. I believe the developer should use whatever URL shortener they feel comfortable with. Once they have one that provides them the correct size and gets them to their final website, they can enter that in. If the developer is lucky to have an small domain name and have control over their own web servers they may not need to use a third party shortener service. A developer can provide their own shortened site paths that redirect to the full path. The Physical Web Service will look up the metadata after any redirection. That is how we do it. It appears that because many sites require some kind of URL shortening and because of the use of third party shortener services, the developers of the Physical Web Services has begun requiring the final destination, if redirected, to be SSL/TLS sites. It also seems that some efforts are requiring SSL/TLS for all sites. It should be noted that the Physical Web Service APP is being ported to Web Browsers directly. The various Web Browsers are implementing their own idea of whether SSL/TLS should be required and when. We are waiting to see how that pans out. But regardless, it something to be aware of. Check out this overview of Eddystone beacon technology and the Physical Web by Tomas Trnka. There are other settings that could be configured using Simblee For Mobile. The Eddystone-URL Beacon packet has a byte representing the beacon transmitter power. It is not the actual programmed power setting of the transmitter. It is the measured power at one meter referred back to zero meters. It is a function of a particular hardware design and transmitter power. If the actual transmitter power can be modified, then this measurement needs to be made for each of those modified settings. The end user should not be able to change this number unless the correlation of the programmed transmitter power and the measurement at one meter is performed. Currently, my beacons have one setting and does not require/allow change by the end user. It should be established by the hardware designer.
|
