I am aware of MOTO G first version has bluetooth issues.
Background:
My app scans for beacons in the vicinity. The app works great on all Android phones except Motorola Moto G, 1st version with Android 5.1. On this phone, it finds all the beacons except one and the scanning is pretty fast as well. However, with this specific beacon (skybeacon), it only detects first packet and after that it takes forever to find this specific beacon while finding others. A simple conclusion is this specification beacon has issues, which might be true. However, it becomes more interesting from here.
To understand this more, I downloaded other BLE scanners from play store. When I used "BLE Analyzer" from bluevoid, it captures this beacon perfectly. I can see RSSI changing as I move the beacon and it is pretty fast. Once I push BLE Analyzer to background and check our app, surprisingly our app works now. I repeated this, 20/20 times my app captures this specific beacon as long as BLE Analyzer is pushed into background (by pressing home button). If I restart or uninstall or wont open BLE Analyzer at all, my app wont capture this specific beacon.
Possible explanations:
For good or bad this specific beacon is advertising in one channel and the default scanning on this specific phone is having a mismatch. If this is in the right direction, then how to change default scanning channels through app?
This phone might have an integrated chip for wifi, bluetooth and 3G, which might be true. When I disable wifi, I do not see any changes in behavior. When I disable data (3G, not 4G on this), it some times (2 out of 10) start capturing the skybeacon. Again 2 out of 10 times is not a repeatable solution.
Any thoughts?
Related
I am trying to find a Chromecast solution, whether I write it myself in macOS/Swift, or there is something already in the works. I came across the Chromecast SDK, but I see it only support Android and iOS. Has anyone had any success porting to a macOS app? I'm interested in a Chromecast solution because the devices are relatively inexpensive considering other wireless HDMI devices out there.
I am an entertainer and my goal would be to replace my HDMI cable with a wireless solution to extend my display (not mirroring the main display on my MacBook Air) to multiple TV's (up to four) for my app, which displays a game log, advertising, and some minor animation for game winners and losers that my patrons see.
Any recommended first steps to coming up with a Chromecast solution, or should I continue looking in other directions?
I need some help because I don´t know how to approach this challenge.
I want to build a device, that's receiving a Bluetooth audio signal and is forwarding it to a Bluetooth speaker. It´s also running some algorithms with the audio data and also simultaneously sending results via UDP to a different device.
I already thought about using two or three ESP32s, using one with an extra Bluetooth module, or searching for a whole different MCU with Bluetooth 5.0 or higher and Wifi 5GHz. But I don´t know approach the best is, or maybe a completely different one.
Some context, why we want to do it:
We want to create a real-time light show, based on the current playing song. It is already working for PC, but also want to make it accessible for phone users. Sadly there is no way to capture the internal audio on iPhone or Android phones. Our Idea to make the music sync with the phone possible is that you are connected with the phone via Bluetooth to our "sync box" which is then connected to the speaker via Bluetooth or AUX. The "sync box" is running our algorithms for creating the light shows and then sending the data to the microcontrollers from the light strips.
So maybe you have an idea how we can sync the lights to the music completely differently or how I can approach the challenge with Bluetooth.
Any help is highly appreciated.
Thanks a lot.
I'm working on a project to track delivery trucks leaving and returning to the office.
While I know RFID would work, we're also looking at BlueTooth with mobile apps. Ideally, once a driver installs the app, we register a unique ID for the device, and a BT reader identifies when phones/deliveries leave and enter range without any user interaction.
From the Android 6.0 release notes, it looks like the MAC address is hidden from apps and BT broadcasting. https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-hardware-id
User management of app installs and enabling BT aside, is this feasible?
Can someone point me in the right direction to confirm what identifiers are available?
When I understand you correctly you actually do not want to track where a phone is but want to know if a person/truck/phone passes a kind of checkpoint or gate?
For newer smart phones you cannot rely on the visible MAC. Bluetooth classic is usually not visible and the BLE MAC is randomized as long as the device is not paired and bonded.
Indeed as PaulW11 stated, the simple way would be to implement an app which does BLE advertising with short advertising interval. Inside this advertisment you can put some custom data. This will be visible to everyone. This ID can be some random number, a number assigned by you or whatever.
At the gate you would implement a BLE scanner grabbing all advertisments near to it.
This should be easy to implement.
I would also like to mention the drawbacks here: If someone passes the gate you may miss him. BLE with Android is always tricky and you might have the situation that the bluetooth subsystem on a phone may have stopped working or so.
One the other hand if someone comes accidently near to your gate, you will think he left or returned. Near can be something around 50 m or so with good conditions or only 10 in other cases.
And even worse: If someone stays 'nearly' in the range of the gate you will see im sporadically. This may confuse your come and go logic if he is visible every 3 minutes or so...
I am developing an app that controls a product's operation. The communication is via BLE. My configuration is
App - Peripheral (iOS, Android)
Product - Central (uses Laird BT900 module)
iOS as a peripheral works fine (pairing and bonding) ; Android PIN pairing works fine, but subsequent bonding (or reconnect when in range) there are a lot of issues and termination of connection. I am using the supported list of devices for Android BLE and I also understand that there are many known issues that come with different manufacturers/chipset vendors
The issue I am getting is, as seen by nrfConnect, is with descriptors. Android app doesnt show descriptors when seen in nrfConnect whereas iOS shows. I do not know what is the difference
Is it a common practice to use a phone as a peripheral ? Or is it a risk - because this is a medical device.
Are there any best practices for Android as a peripheral ?
I have following back up plans in case Android issue is not resolved. I think following would work on any BLE supported phones without having any issues with the variability.
Plan A : PIN pairing on every connection with the product. This is the most secure and most annoying
Plan B : Implement just works pairing with a app layer password before taking control of the product.
Question : Is just works safe and encrypted ? Is it snoop-safe or MITM-safe ?
Thanks in advance!
A few thoughts from your questions:
1a. (From my Android experience) I think its uncommon to have the phone be the peripheral. To my knowledge all iOS devices support peripheral mode but only a very small subset of Android devices are able to support it. I say this because I've been experimenting with BTLE beacons using the AltBeacon library. From this work I have discovered that only certain Android phones can broadcast BTLE advertise packets. Given that BTLE advertising is the first step in initiating a BTLE session I imagine that this prevents many Android phones from being compatible with peripheral mode.
If all of your users can use an iOS device, then you're set, otherwise this may be a problem.
1b) I can't speak to the specific risk of using a mobile device with your medical device, that depends on what the medical device is doing and how you're using the mobile app.
2) See 1a
3) The specific encryption scheme you used is also based on your product's risk profile. I would say that Just Works is not an ideal solution. The just works pairing process is not snoop-safe and can be re-initiated via a MITM. Other than that I can't speak to the strength of BTLE encryption.
if i want to develop own my iBeacon services in Android or IOS, it has to be practical. which means customer can use my services without shortage of battery.
i think even if iBeacon technology is based on Bluetooth Low Energy, it could be still lack of battery. that's because an application must be running to scan iBeacon device all the time.
As i know, iOS has its own solution for battery issue. when an IOS application detect iBeacon devices, it is running in the background and IOS(not app) is scanning specific UUIDs by itself, not the all UUIDs nearby. this is how they save energy. am i right?
but in case of Android, any solution for battery issue is not provided. what's more,
when an Android application detects iBeacon devices, it scans all the UUIDs nearby and it deals with everything, not the Android OS. is this right?
so Im worry about this battery problems, before i start to develop own my services.
is it gonna be ok with battery?
is there any good solution to share?? how do you guys solve this problem??
The Pro version of the Android iBeacon Library comes with an automatic battery saver that slows down scans when the app is in the background to save battery. The open source Android iBeacon Library also allows configuration of a foreground and background bluetooth scan rate, and provides methods to call to tell the library when the app is in the foreground and the background.
On iOS the battery saving strategy is similar. When no app is ranging for iBeacons in the foreground, bluetooth scans are not performed constantly. The exact frequency of background scans is not published, but I have measured it happening once every 15 minutes on a iPhone 4S with iOS 7.1.
Scanning for specific UUIDs has no effect on battery life. At the OS-level, a Bluetooth LE scan looks for any Bluetooth LE device that is advertising regardless of whether it is an iBeacon or whether it has a specific UUID. The filter for specific UUIDs is handled in software at a higher level.