As a beginner in ibeacon technology, I've been trying to get an answer to the following question online but I couldnt find anything that comes close to it!
So here goes...I'm aware that there are hardware ibeacons (eg: by Estimote, Radius Networks etc..) and then there is an iphone which can act as an ibeacon. My question is : When I receive a signal from an ibeacon, is it possible to distinguish whether the signal is from an iphone ibeacon or a hardware ibeacon?
Using the basic CoreLocation APIs, all beacons that meet the iBeacon specs will be indistinguishable. You can make some guesses (e.g. does the beacon use the default Radius Networks or Estimote UUID?) but these won't always be reliable.
If you have access to a proprietary configuration SDK for the hardware beacons (hardware beacons are sometimes configurable via Bluetooth), you might be able to use the CoreBluetooth APIs to try to connect to the beacon and determine its manufacturer. But doing this would require you to write different code for each proprietary hardware beacon you might encounter. You have to decide if this is worth the trouble (it's a lot of work) especially since you'll never be able to cover all the different hardware beacon types out there.
Related
So recently, Casting technology is almost poping up everywhere i know, and those Smart TVs and TV boxes starting to "claims" to support such technology, and i was like hmmm, how do they works? wat protocol they use?
and one day, as im a Nexus6P user, which built-in a feature of "Casting" on it, and my friend claims that his TV support "Casting" feature, and then he use his IPhone to drop his screen onto his tv, but when i try to open my Casting feature, it won't find the TV devices, and i tried all my devices on my hand such as PC(Chrome), and even tried some 3rd parties software, no lucks. (mostly they just use the API of phone built-in casting protocol, which is useless)
And the the funny thing is, some random video platform software in China, BiliBili found the devices and work likes a charm, with my Nexus6P, so im completely confused and did some research on Protocols of Casting Technology, here are the information i've found
Here are the protocols of Casting Technology list i got
DLNA/UPNP casting (Media streaming)
This is probably the oldest protocol of casting technology, DLNA was originally developed for media transfer just like FTP, it probably send signal to the receiver device and ask it to receive data feed from the source, as it was not designed for Casting technology, it leaks of feature such as playback controlling and video streaming, and it need application to write its own data feeding codes, thats why there is only a few big brand software in the market support such protocol.
(Fun facts, Windows also support this protocol hiddenly)
Chromecast Built-in (Google Cast)
Chromecast, obviously developed by Google, and this one is directly designed for the casting technology only, such protocol seems is the leading one in the market, one fun fact is, Chromecast Built-in Projection device seems also able to cast on device that uses Miracast
Miracast
Miracast, developed by Wi-Fi Alliance, an extend of Intel WiDi, is probably the second choice in the market, and its widely used in China as it has no relation to Google, also Windows built-in this protocol too, kinda powerful as Chromecast too
[Deprecated] Intel WiDi
No longer supported
AirPlay
Developed by Apple, well they have their own market thats isolated from us... watever, but this protocol is the most useful one, as AirPlay projection devices is able to project on all of the devices used any protocols above, which is really powerful, give one like to apple this time, only
Sources
https://newsletter.icto.um.edu.mo/wireless-display-and-screen-mirroring-technology/
https://en.wikipedia.org/wiki/Google_Cast
some random china website i forget
If there are any incorrect information or missing, plz notice me im willing to update them, im just
trying to tidy up all the protocols we have, as internet seems leak of information on such area
so now comes with my questions
as DLNA/UPNP is the oldest Screen Mirroring Technology, why google and WiFi Alliance has to develop a new protocol for casting? you might tell me because its leak of control such as playback one, but if u have ever used BiliBili, or this one i found in the PlayStore "Video & TV Cast for DLNA Player: UPnP Movie Mirror" by 2kit consulting, u will notice that actually there is some kind of way to control it, even streaming Youtube. currently i can't find any opensource project of DLNA casting player too, why is everyone dont want to update DLNA and just heading into a new way??
Can i use Miracast enabled projection devices to cast on a chromecast device?? Say i want to use the Windows' built-in Miracast to cast on a Chromecast Built-in device
Currently, casting technology also seems leak of security, you can easily project on neighbor's TV without permission, ppl even play adult video or horror video to trick the others.. why no one care about that? even google??
Miracast from ethernet to Wifi?? why such thing still not exist?? according the information i got from internet, the projection device must be using WiFi why??
I want to know if I can setup altbeacon uuid, major and minor with altbeacon library for any beacon hardware that support altbeacon layout. I haven't seen this information in any place. Because of operational reasons, I need to set them up remotely, with open source software. All of them are proprietary. I am looking for an open source solution for set them up. Any help or information would be apreciate it.This question is related to altbeacon, because I couldn't find a non property solution for ibeacons.
Altbeacon is 'old' and not used so much now. In any case, it sends out a URL, not unique id(s). You should instead look into Eddystone if you really don't want to use iBeacon. All beacons just use 'standard' Bluetooth advertising so there's nothing to stop you designing your own Bluetooth advertising payload. There's an overview of advertising at BeaconZone.
The Android Beacon Library does not provide a SDK for configuring beacon identifiers. Unfortunately this is not possible because every beacon manufacturer has a different way of configuring their beacons, and the mechanisms are often proprietary and does not have a published API.
The open source AltBeacon standard is supported by a wide variety of beacon hardware manufacturers. However, there is simply no standard way of configuring the identifiers. You must follow manufacturer instructions.
As far as I understand eddybeacon (just released by Google) is effectively a new 'operating system' for Bluetooth 4.0 Low energy devices (iBeacons). I have been experimenting with iBeacons for sometime now and want to try out a few things with eddybeacon. Has anyone had a go with it yet? I've read a few sites and they say it can be installed to some devices... Can anyone share how to do this?
If you want to start out by playing with Eddystone, you have a couple of options:
You can use a software transmitter. Just download my free Locate App in the Google Play store which will both act as an Eddystone transmitter and decode other Eddystone-compatible beacons in the vicinity. Google also has posted an Android app that can transmit the Eddystone-UID frame here, but you have to compile it yourself.
You can get a few hardware beacons for testing with a Developer Kit from Radius Networks (my company) here.
Once you have a transmitter, you can try writing some software to work with it. Here's a tutorial I wrote on how to build a basic Eddystone-capable Android app.
One other thing that might be useful is an Eddystone detector tool. You can use the free Android Locate app to detect and decode all of the frames transmitted by Eddystone.
So:
Eddystone is a specification for Bluetooth Smart (usually just called BLE) devices to behave like beacons — it defines the Bluetooth frames and content they need to broadcast to be seen as beacons.
iBeacon is not a generic term. iBeacon is actually Apple's specification for Bluetooth beacons. Eddystone and iBeacon are both examples of beacon specifications for BLE devices.
There are a few ways to get started with Eddystone beacons.
a. A number of hardware manufacturers sell developer kits that will let you get started with Eddystone beacons right away, and there is plenty of example software out, either from those vendors, or from the google pages on GitHub — github.com/google/eddystone and github.com/google/beacon-platform.
b. Some people have had good luck with Arduinos and Raspberry Pis. You can see an Arduino example here (Note: I have no idea how well that project works, I've just seen it used a few times.)
Is it possible to use an iBeacon to get the UUIDs of all devices in its radius? I tried searching this up, but I couldn't find a definitive answer.
Technically speaking, iBeacon is a standard designed for broadcast-only, meaning that it can only advertise data (UUID, Major, and Minor). However, there's nothing stopping you from building a device that's more than just iBeacon. Actually, most of the beacons available today are more than just iBeacon hardware, with connectivity mode and adjustable settings, which goes beyond what's specified in the iBeacon documentation.
A good example of a device like that is an iPhone. You can make your iPhone act as an iBeacon (at Estimote, we call this Virtual Beacon: https://community.estimote.com/hc/en-us/articles/200908836-What-s-Virtual-Beacon-) and still have apps installed that are monitoring for other iBeacon regions.
Cheers.
Can I use Serial Port Profile (SPP) to communicate with iOS devices over Bluetooth Low Energy (v4.0) without the need for MFi Chip?
If you're designing something from scratch (rather than trying to interface to an existing SPP-enabled device), there is a possible solution.
Laird Technologies make a Bluetooth Low Energy Module (BL600), which can be loaded with a virtual serial port application. This creates a service which is similar to the SPP; at the remote end it can just be treated as a plain serial port (albeit rather low speed). You could roll your own service to do something similar on other devices.
It's not the most elegant solution, but seems to work okay, and far easier than trying to get MFi certification.
If you cannot control the peripheral's protocol choice:
The Serial Port Profile (SPP) is still supported by Bluetooth 4.0. However, Bluetooth 4.0 Low Energy uses different pysical and link layer protocols that are not backwards compatible with older Bluetooth standards. Current iOS and Android devices use "dual mode" interfaces that support the backward compatible part of BT 4.0 and the Low Energy standard.
Bluetooth 4.0 Low Energy does not support SPP whereas regular Bluetooth 4.0 does!
I found a Cordova/Phonegap Plugin on GitHub that might serve as a source of inspiration for you. They advertise to support SPP on iOS and Android alike.
If you are in control of the peripheral, i.e. you implement the peripheral's software:
Bluetooth 4.0 Low Energy communication makes use of the Generic ATTribute Protocol. Based on GATT there exist a number of profiles but no serial port profile.
The good news is that implementing your own proprietary serial port profile on iOS, Android and your device is fairly simple. The API instructions for your BTLE module/SoC should provide some examples for existing profiles.
As soon as you see how simple implementing your own profile is, you will probably choose to go for a more use case specific profile which will save you lots of power on your (battery powered?) peripheral.
Just to clear up John Parsons comment from Feb 16th - the BL600 is definitely not discontinued whatsoever.
vSP works well for a low level, low throughput data connectivity using BLE for iOS devices, as well as Android. Video showing the solution working to an iPad are at this link and full source code is available for the iOS application as well http://www.lairdtech.com/Support-Center/Technical-Library/Videos/VSP-Bridge-Command/#.UwYvzGJ_s1w
There are no MFi requirements for BLE connectivity on iOS.
MFi is only relevant to Classic Bluetooth data connections to / from iOS devices, where you need to use Apple's iAP protocol, be a MFi licensee, use an external Apple Authentication IC and pay a royalty to Apple.
NO,you can't. BLE not support SPP.
No, you can't. In general, it's important to remember that any Bluetooth Classic profile isn't necessarily applicable for Bluetooth Low Energy. With BLE however, you can easily create your own custom service/profile, specially tailored towards your particular application. As far as I know, all BLE communication with iOS is currently allowed without participating in the MFi. You can also take a look at this page for further information on SPP and BLE.
I'm searching for SPP for iOS myself and found a German supplier, lintech.de, that has products for "Bluetooth meets Apple" claiming to support/emulate SSP, apparently using their own embedded software layer combined with iAP. "BlueMFI software communicate with APPLE devices using the iAP (iPod Accessory Protocol) and manage the data communication with the Apple authentication chip...BlueMFI software is designed to run on a variety of hardware platforms (Bluetooth modules), and interested users can obtain the relevant evaluation kits. LinTech’s Bluetooth modules with BlueMFI software not only support the APPLE iAP protocol via Bluetooth, but they are also able to communicate with standard Bluetooth devices." Haven't tried this yet, just exploring and sharing.
I won't say SPP is directly supported under iOS 7, Apple says no. Won't argue :)
But...
I use connectblue modules OBS421 and OBS425 on a data collection project.
BLE modules have SPP profile enabled and I transmit data from my sensors to the iOS devices using BTLE module in SPP mode.
Works pretty fine under iOS 6 and 7
That said, I was having trouble with MFi bluetooth devices under iPhone 5S, that's why I moved to BTLE.
Drawback with BTLE, it's limited to 20 bytes at a time.
I had to adjust hardware and software, but was easy.
You have programmable chips such as Bluegiga BL112 that are doing the job. It is the cable replacement code.
I'm integrating it actually for both iOS and Android 4.3. It works at least on the demo board.