Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 7 months ago.
detailed explanation of working URIBeaconConfig
Hi,
I had some troubles understanding how configuration was done. I studied the code and wrote down how it works in my opinion (please correct me where I am wrong).
There is also documentation here: http://docs.mbed.org/docs/ble-intros/en/latest/GettingStarted/URIBeacon/
maybe it can appended with these findings?
/ URIBeaconConfig: how does it work?
- simple explanation: the beacon starts in a connectable state, then every 60 seconds a Ticker interrupt callback checks if the beacon is still connected to te phone. If the beacon is not connected to the phone then the callback alters the mode of the beacon to non-connectible mode (=only advertising mode), and also prevents the ticker from firing again. this ensures that the beacon is only configurable in the first 60 seconds after reset. After that the beacon will only advertise.
detailed explanation: in 'main' the class uriBeaconConfig = new URIBeaconConfigService(...) is called in this class in line 146 this function is called: setupURIBeaconConfigAdvertisements() this function opens the beacon for configuration (by calling setAdvertisingType with ADV_CONNECTABLE_UNDIRECTED) the beacon will remain connectable until setAdvertisingType is changed to ADV_NON_CONNECTABLE_UNDIRECTED, and this is done by function setupURIBeaconAdvertisements() which is called in timeout() the actual configuration is done by an android app that is CONNECTED to the beacon
a) the user did not update the configuration: then the configuration stored in flash will be used. immediately the program proceeds and eventually enters the while loop, and the beacon's old data is advertised (broadcasted). after 60 seconds the Ticker interrupt processes the 'timeout' function. this function checks if configuration is still ongoing (connected state). there is no connection so the 'if'-statement is true, hence this function is called: setupURIBeaconAdvertisements() the aim of this function is to switch to the non-connectible normal mode for URIBeacon. then advertising is started and the interrupt detached so it can not be called anymore. the beacon enters its endless while(1) loop and starts advertising
b) the user did update the configuration: a new configuration will be stored in flash memory of the beacon. then when 'timeout' function kicks i after 60 seconds (Ticker interrupt) it checks if the beacon is still in connected state. If the configuration is already done, it will proceed as in (a) If the connection is still ongoing (configuration is not finished yet) then the timeout function exits. after 60 seconds it will kick in again (Ticker interrupt), to check again if it is still connected, etc. when eventually the connection stops, it will proceed as in (a)
- /
Question relating to:
2 Answers
8 years, 7 months ago.
The URIBeacon starts in a connectable state and remains so for the first 60 seconds. This 60-second interval is tracked by a Ticker. At the end of the timeout, the URIBeacon switches into non-connectable beacon mode for the rest of its lifetime (terminating in a power cycle); alongside this switch, the timeout callback is detached so that no further timeouts are generated. If the timeout callback finds the beacon in a connected state, it doesn't switch out of the configuration mode directly; the timeout callback is repeated generated at intervals of 60 seconds until the beacon is found in a non-connected state, at which point there is the switch.
I believe these details should be documented in the URIBeacon (or Eddystone) spec.
Thanks Rohit, thank you very much for your answer. I have some questions though:
You say "At the end of the timeout, the URIBeacon switches into non-connectable beacon mode for the rest of its lifetime (terminating in a power cycle);"
1) how does this exactly happen? which code exactly, is responsible for this.? 2) what do you mean by "terminating in a power cycle"?
Tx
posted by 01 Sep 20151. The transition to non-connectable and non-configurable beacon-only mode happens at https://developer.mbed.org/teams/Bluetooth-Low-Energy/code/BLE_URIBeacon/file/6282226b1b8a/main.cpp (line 47, 48) setupURIBeaconAdvertisements() will re-initialize the gatt server; clearing away the config service. It will then setup a simple beacon advertising payload.
2. The only way to pull the URIBeacon out of beacon-only mode is to power-cycle the device.
posted by 02 Sep 2015
8 years, 7 months ago.
Hi, Rohit
I have several questions about URIbeacon:
1) If the Physical web connected and configured the beacon within 60 seconds, will the timeout callback detect a connected or disconnected state?
2) I'm using iphone6 and installed a physical web. the display of my uribeacon is very slow (and not stable) even if I changed 60s to 5s, (only stay in connectable state for 5 seconds) and I also called ble.gap().setAdvInterval(1000) to advertise every second. What's wrong? Is it the problem of the firmware or Apps?
3) Seems I can't open the URL displayed in Physical web, it redirect to an appspot web which is inhibited by china gov. Why not go to the web URL that beacon advertised directly?
Hello Neo,
1. if your physical-web application (or generic BLE control panel application such as light-blue or Nordic MCP) connected to the URIBeacon, configured it, and *disconnected* before the 60-second interval, then the timeout callback will detect the URIBeacon in a disconnected state and switch to beacon-only mode.
2. I don't understand what you mean by the display being slow. I suggest you try an alternate application (light blue or Nordic MCP) to get a different perspective. If you changed the timeout interval to 5 seconds, then it makes sense that your URIBeacon would remain connectable for only 5 seconds.
3. if you're getting redirected to a different URL by the Chinese government, then that is an independent issue altogether. We cannot comment on that.
posted by 04 Sep 2015