I'm using the altbeacon android reference library for detecting beacons.
There is an option to configure the parser to detect other non-altbeacon beacons e.g. Estimote (as described here) by adding a new BeaconParser (see this) which works a treat.
However, how do I allow it to detect ALL beacons of any UUID/format (altbeacons, estimotes, roximity etc)? I've tried no parsers, blank parameters and without the "m:2-3=.." parameter. Nothing works.
Thanks
You can configure multiple parsers to be active at the same time so you can detect as many beacon types as you want simultaneously. But there is no magic expression that will detect them all.
Understand that the BeaconParser expression tells the library how to decode the raw bytes of a Bluetooth LE advertisement and convert it into identifiers and data fields. Each time a company comes up with a new beacon transmission format, a new parser format may be needed.
Because of intellectual property restrictions, the library cannot be preconfigured to detect proprietary beacons without permission. This is why you must get the community-provided expressions for each proprietary type.
Related
When receiving an output from IMFTransform::ProcessOutput, calling GetUINT32(MFSampleExtension_CleanPoint) on the sample fails and returns MF_E_ATTRIBUTENOTFOUND only while using the AMDh264Encoder (NV12 in, H264 out), as such there are no keyframes in the final output video so it is corrupted.
What causes getting attribute MFSampleExtension_CleanPoint MF_E_ATTRIBUTENOTFOUND to fail, only on the AMDh264Encoder?
Video encoder MFTs are supplied by hardware vendors. AMD does "AMDh264Encoder" for their hardware and introduces it with their video drivers, in particular.
For this reason implementations from different vendors have slight differences, AMD guys decided to not set this attributes on produced media samples.
You should skip this gracefully and treat the attribute as optional.
I have a BLE device with multiple characteristics addressed by default addresses as defined here
Things like Manufacturer Name String, Hardware Revision String, Serial Number String etc.
Using the UUID class I've attempted several different ways to construct a UUID that RxAndroidBle would accept and read from these characteristics.
The one I though would work most was this:
UUID GATT_DSR1_MANUFACTURER_NAME = new UUID(0L, 0x2A29L);
but I just get back onError callbacks.
RxBleConnection.readCharacteristic only accepts UUID or a BluetoothGattCharacteristic which is created with a UUID...
Creating UUIDs
(copied from How to correctly use UUID.fromString method? )
In the BLE specification there are two kinds of UUIDs.
Fully qualified 128 bits long which are usually assigned for a specific vendor of the BLE device for non-standard functionality: UUID.fromString("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx");
Also fully qualified (but defined by standard) UUIDs which have the same prefix and postfix: UUID.fromString("F000xxxx-0451-4000-B000-000000000000"); UUID.fromString("0000xxxx-0000-1000-8000-00805f9b34fb") where xxxx is the place to fill the four characters you get from the SensorTag Bluetooth Core specification. For convenience the standard UUIDs are usually referenced with the four characters identifier.
Your 0x2A29L stands for "2A29" String as the xxxx.
Obtaining BluetoothGattCharacteristic
On Android there is no possibility to create a working BluetoothGattCharacteristic with a UUID. It is still possible to call RxBleConnection.discoverServices() and get it from the result though.
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
My question is more specific to GSM mobile telephony networks and more or less about SS7/SigTran Protocol suite. So I am not asking the possibility of knowing SIM card details using IMEI number from an end user point of view as it is asked here.
Being a network operator is there anyway that I can retrieve the IMSI associated with IMEI number from MSC,VLR, HLR or any other network elements in the core network(I am excluding EIR on purpose as my current implementation does not include that)? The query should be just based on IMEI with an assumption that we are not interacting with the SIM or the device. Do any of these elements store IMEI-IMSI pair when it is used before.
In summary is it possible to retrieve IMSI from the database of any of the network elements provided just IMEI number. If yes, how? what are the messages (e.g. provideSubscriberInfo-req) that are needed and the ASN1 encoding scheme.
P.S: This is not handset specific such as the one mentioned here , more of network operator specific.
Well its not possible(not that I know off) from a standard GSM operation where you can input IMEI and receive IMSI. However you can get IMSI if you know the MSISDN by GSM Map operation Any_Time_Interrogation_Request. We are using a solution from sigtrangateway.com SigtranGateway.com for same purpose in a telco project and its working fine so far.
I'm trying to make an Android program that will always scan for a specific Bluetooth device, and alert the user when the phone is within proximity.
I modified the demo code provided here: https://github.com/devunwired/accessory-samples/tree/master/BluetoothGatt
The second demo here, (titled "BeaconActivity,") constantly scans for Bluetooth devices with the thermometer service. For testing purposes, I am trying to make it scan for the proximity of an Estimote. I do not want to use the provided Estimote SDK since I plan on using a more generic Bluetooth device in the future.
In the above "BecaonActivity" a UUID for the thermometer service is defined. I tried switching this number out for the UUID for Estimotes defined on this page: https://community.estimote.com/hc/en-us/articles/200761958-Advertising-Packet-Estimote-s-Proximity-UUID
From the above linked source code, there is also a "TemperatureBeacon" class that has a "short-form UUID" of "0x1809." I realized that this was just the 5th-8th character in the full thermometer service UUID, so I changed it to "0x7F30".
After mostly just changing the UUIDs and leaving most of the code the same, I tested it on my phone, but it could not detect the Estimote. Any ideas about what I'm doing wrong?
This is Wojtek Borowicz, a community evangelist at Estimote. We're not ready yet to make specs for thermometer available for Android. Stay tuned!
Cheers.
I am not familiar with the demo code you provided but did you actually try to use the estimote proximty uuid (https://github.com/Estimote/Android-SDK) ?
private static final String ESTIMOTE_PROXIMITY_UUID = "B9407F30-F5F8-466E-AFF9-25556B57FE6D";
This might be helpful as well:
Check if Bluetooth Low Energy Beacons are nearby in Android
As David points out, for android devices you do not really have to consider UUIDs or services
if you are only interrested in proximity.