Using the RadiusNetworks Proximity Kit, I have created a kit. Within the kit, I have created a region and registered my dev beacon. Next, I have attached key/value attributes to the beacon. My question is, once synched are these attributes physically stored on the beacon?
This article confuses me. Per this article:
They don't deliver anything. They simply broadcast a few identifiers.
Beacons broadcast a UUID, Major Value, and Minor Value. No user
consumable content is broadcast, just these IDs.
Along with the other info (UUID, major and minor versions), don’t these beacons also broadcast the key/value pairs?
iBeacons can only transmit one type of data: the UUID number. Beacons using the new Eddystone standard can transmit three types of data: UID (similar to UUID), URL (website addresses) and TLM (telemetry, such as temperature and beacon battery level). Standard beacons don't have any memory to store arbitrary data, but you could work around that by using the Lightblue Bean or building a custom beacon from Raspberry Pi. Like already mentioned, another option would be to use a backend, where you store and retrieve the data. We did a museum application that functioned with iBeacons using our Proximi.io platform, which is able to store the data for temporary offline mode, and re-syncs, when Internet access becomes available again. A third option would be to just build in all the data into the application.
Looking at the Proximity Kit Documentation, step 2 of the lifecycle says that your app will sync with their back end and that your "region data and configuration is cached and can be updated in the background."
I believe that your key/value pairs are stored in the cloud (and synced to your mobile device), and not stored on the beacon (since there is no way for their back end to connect to a beacon).
Related
Suppose I have a SIM (which can be used to send SMS when plugged onto a phone of course), how can I send SMS using this SIM number when the SIM is not plugged to any device(i.e., just put it away)? Note: I don't mind what platform the sms is sent from (e.g., it can be sent from a PC, a smart phone), so any possible solutions? I don't mind solutions which involves coding or programming (e.g., by calling APIs) as well.
Note highly simplified/high level answer:
In order to send an SMS, USSD, Call or Data etc the Mobile Network will need to provide the device with a special "key" that is used in the communications. I.e. to send and SMS you will need an encryption key to tell the network to send an SMS.
The issue is that this key is dynamic, it changes based on network configuration. The only way to get a key is to use your SIM as it contains a component of the key.
SIM cards (and Bank chip cards) are really a marvel as they are a very good example of superb security, they have been around in Billions of units for more than 30 years, but have and continue to thwart hacking attempts for the most part.
To answer your question, You need the SIM card to get access to production mobile networks.
If by saying "SIM is not plugged to a phone" you still Ok about SIM to be plugged into some other device - you defintely can use USB/GSM-modems and standalone GSM-gateways.
Also you may want to consider hardware solutions such as GSM-gateways+SIM-banks. SIM-card is placed in the special non-GSM box (SIM-bank) and available for remote commutation into GSM-box (gsm-gateway) via Internet/Ethernet. Commonly SIM-bank holds hundreds of sim-cards remotely available, and GSM-gateways have only few dozens of real gsm-channels (due to hardware cost saving). Everything is controllable via manufacturer-specific API and/or GUI.
Background: I have an app which runs on an Android handheld (phone) but whose main purpose is to interact with an Android Wear watch. Correspondingly, the main source of data in the app is the wearable (not the handheld). I'm not currently using the DataApi to send this data from the wearable to the handheld; I had some issues with its reliability in the early days of Android Wear, so I rolled my own using the MessageApi.
Separately, I also cache the data I receive from the wearable in a SQLite database (on the handheld), so that my app has something to work with when the devices aren't connected.
Both of these pieces are working OK, but involve quite a bit of code. My question is, could the DataApi replace both my messaging layer and my local cache?
Obviously, the answer to the first half should be yes. This is what the DataApi is for, and in testing recently, it seems to have stabilized considerably since I first tried it out.
The second half is much less obvious. On paper, it looks like it could; the DataApi includes methods like getDataItem() which, apparently, can be used to retrieve data items which were synced previously. But this isn't its main function - is this aspect reliable enough to, well, rely upon for my app's main data storage?
Yes. DataApi actually uses sqlite to persist data on both devices. You are duplicating efforts, if you are using MessageApi and your own persistence.
i do not suggest using data api for data cache, because
1. data api queue cache has space limit, last time my test result is about 10MB
2. data api can not detect each data item if you put the same data content
3. data api may be deleted after use the item.
To learn CB, I've decided to browse the services on my iPhone. I'm finding a few, but except Battery and Time, the others are "Unknown". What is it?
Some services have defined UUIDs (such a battery and time) and these are listed on the Bluetooth Developer Portal. The defined services also have a set of defined characteristic IDs
BLE also allows developers to specify their own service and characteristic UUIDs - since the chance of collision for random UUIDs is infinitesimal, there is no requirement to register these, but organisations may choose to document them. Apple's notification center service defines some, for example, and many chipset/module vendors define services to make it simpler for developers to use their modules.
Looking at my Fitbit Flex I can see device information and battery services - these are well known, as well as two unknown services which, presumably, FitBit use to transfer activity and configuration information to and from the device. Short of trying to reverse-engineer their protocol there is no other information available on these services and characteristics.
I wanted to know what NFC Execution environment means actually. In forum documents it is described as "An environment, either built into the NFCC or connected to the NFCC, where NFC applications are executed. The NFCEE may be included in entities with various form factors, some of which can be removable or replaceable.". But the Device Host(an application microprocessor like OMAP or Snapdragon) is the one which interacts with NFCC, as per my understanding in the mobile environment. Can anyone give me a example of what NFCEE can be - I mean is it another hardware module(if yes, which) or an android library to execute apps? What does "form factor" refer to?
The Execution Environment is in most cases a hardware module.
Newer SIM cards have a pin to connect the SIM to the NFC chip. Inside the SIM an application (payment for example) can run in a secure environment and talk to the NFC chip. Payment goes from a sales terminal through the NFC chip directly into the SIM without ever passing data through the application processor. So there is no easy way for malware to monitor or modify the payment process. That's a simplified view of the secure aspect.
Other execution environments are:
Embedded Secure Elements. These are in a nutshell SIM cards that are in the same package as the NFC controller chip. Your Android Phone most likely has one of these, called the SmartMX chip.
SWP (Single Wire Protocol) enabled SD-Cards. Same thing as a SIM, but in the form factor of an SD card.
The concept doesn't end here. There are for example experiments to move the execution environment to the application processor. For ARM CPUs there is the TrustZone extension which allows to execute code on the main CPU while still beeing secure.
In the Android API Execution Environments do two things:
they allow you to enable or disable the secure element by setting a route. The route configures when the secure element is active (e.g. has access to the NFC chip) and when disabled. Currently there are two routes in use: Route off (turns off the entire EE) and Route_OnWhenScreenOn (EE active when screen is on and unlocked).
For secure elements that are connected exclusively to the NFC chip (embedded secure elements) the Execution Environment also offers a secure way to exchange data from the application processor to the embedded secure element. This is used to install applications within the embedded secure element (among other things).
That's it in a nutshell.
There may actually not be an answer to this question, but I wanted to post here just in case because it will require some out of the box thinking. This may not be a programmign question per se. If it isn't, rather than downvoting, perhaps you can suggest another stackoverflow site to use for this specific question?
We have installed, and have running, an SMS gateway from SMS Tools 3 (http://smstools3.kekekasvi.com/) and I can receive / send text messages.
Additionally, we have created a custom SMS application for Android / iPhone that embeds GPS location data into the sms message, but we are trying to figure out a way to obtain location based data from a user using a dumb phone (think NGO in Africa with users using the most basic of phones).
Is it possible to get location based data from a SMS message from a phone that lacks wifi/GPS? The only thought so far would be to somehow get the cell towers used by working with cell phone providers in the targeted country.
Thoughts?
Note: This is not an attempt to track users location unknowingly (else we wouldn't have created our custom SMS message application)
You can always do GSM tower triangulation (first iPhone did that) and you don't need to go to all operators - a lot of services out there.
Cellular localisation methods which do not use WiFi, GPS (and other satellite-based navigation systems) depend heavily on the radio access network (RAN), so will vary depending on the type of the operator network , (GSM/CDMA/UMTS/LTE etc.). Its important to understand this because often there are multiple types of networks coexisting in the same country, which can result in varying performance of the positioning scheme used.
Since your question specifically mentions GSM, lets stick to it. GSM cell triangulation encompasses different schemes for obtaining location info of the subscriber. Broadly, these schemes fall in two categories: Network-based and Terminal-based.
Network-based services require signaling in the operator's Core Network (CN) and could be triggered by an agreement with the operator. Technically, this occurs when a call is made or an SMS is sent to a pre-defined emergency number. For more technical details, refer to the ETSI spec [1]
*The drawback: Requires operator support!*
Terminal-based services are dependent on the presence of some location service on the mobile phone - GPS, Wi-Fi, Internet etc.. In the absence of these, there is conceivably only one solution: Have the Mobile Terminal (MT) send its cellular location information - [ MCC + MNC + LAC + CellId ] to the RAN which can forward the information to a GIS service than obtains the Lat/Long of the user. One GIS service that's freely available is Google's geolocation API [2]
[1] http://www.etsi.org/deliver/etsi_ts/101700_101799/101724/07.03.00_60/ts_101724v070300p.pdf
[2] https://developers.google.com/maps/documentation/business/geolocation/