Using ONVIF, how can I determine if the device has a fisheye camera and subsequently if it supports dewarping stream?
In ONVIF, For any feature to be confirmed as supported by the device usually can be done in one or more ways (including but not limited to the list) listed below
Reading the device/service capabilities using GetServiceCapabilities interface provided by every service
Reading the configurations provided by device using 'Get[entity]Configurations' interface
Reading the configuration parameter options using Get[entity]ConfigurationOptions interface
The "entity" varies depends on the feature, Check the entities list here
https://www.onvif.org/specs/srv/media/ONVIF-Media2-Service-Spec.pdf Section 4.1 Media profile)
For your query about dewarp feature support, option 2 has to be checked. So you have to read VideoSourceConfiguration from the device via 'GetVideoSourceConfiguration' interface and check the response.
The response from device shall adhere to the specification as quoted below
Ref: https://www.onvif.org/specs/srv/media/ONVIF-Media2-Service-Spec-v1712.pdf
Section : 5.2.2 Video source configuration
View Mode
Fisheye – Undewarped viewmode from a device supporting fisheye lens
Dewarp – Dewarped view mode for device supporting fisheye lens
Related
I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
To build a BLE app, you need
service UUID
the service's characteristic UUIDs
the characteristic's permissions (read / write / notify ...)
If you are sending any data, you need to know the value type (uint8_t, uint16_t ...)
For an instance, if it was environment sensing service, I can read this PDF from this page, and find Environmental Sensing under GATT Service and the UUID is 0x181A. Then I can go on reading the same PDF and find Temperature (although it's T emperature in text for some reasons, and it can't be searched by Temperature) under GATT Characteristic and Object Type, and the UUID is 0x2A6E.
OK, so far so good. Then I hit a wall. How about the data size (e.g. uint16_t or whatever) to notify or which permissions are allowed (e.g. read / write ...)?
After hours of googling, I finally found this github and this github. But this is not official, somebody copied and evacuated them.
How do you efficiently program a BLE app when you don't have official XML files to look up?
From the GATT Specification page there is the GATT Specification Supplement document where it has the information on the structure of the temperature characteristic:
Environmental Sensing Service document also on GATT Specification page details if a characteristic can have notifications:
I also found the XML documents presented the information in a more compact manner and I have bought this to the attention of the Bluetooth SIG but the links don't seem to get fixed. The data is still there on the site if you can workout the URL. I have no idea if that data is being maintained.
https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Services/org.bluetooth.service.environmental_sensing.xml
https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Characteristics/org.bluetooth.characteristic.temperature.xml
All of the GATT xml specifications can be found here:
https://github.com/oesmith/gatt-xml
Is that possible to change the default media profile manually?
I've checked out documentation:
media onvif docs
And due to the docs, "default profile" is chosen via device capabilities:
Real-time video and audio streaming configurations are controlled
using media profiles. A media profile maps a video and/or audio source
to a video and/or an audio encoder, PTZ and analytics configurations.
An ONVIF compliant device supporting the media service presents
different available profiles depending on its capabilities (the set of
available profiles might change dynamically though).
Which profile will be chosen, if the couple of them fulfill the capabilities?
Can I change the default profile by onvif's media API? If not: How can I simulate capabilities' change?
Any help would be greatly appreciated.
I have tested with several brands of cameras. They all have some 'default' profiles mostly a mainstream(high quality) and substream(low(er) quality). I found out that the order of the profiles on the devices are random but can be set manually with the device software interface. So if you want for example the mainstream first you can confige this on the device software. Then the next time you connect to the first available profile it will be the one of your choise.
Setting the profile after getting them through the media client (with GetProfiles) can be done as suggested by LoukMo's comment.
Is it possible to search for beacon data (uuid, url, ...) with a progressive web application using just web technologies that is without using native mobile technologies (Android, ios, ...)?
Thanks in advance.
Unfortunately, this is not possible as of July 2020. While Google has been working on the WebBluetooth project to bring support for many bluetooth operations to the browser, at least in Google Chrome implementations on Android 6+, Mac or ChromeOS.
Scanning for beacons is not yet possible as of this writing. The API requires that the OS scan for devices matching a requested criteria, and then let the user choose a device to connect to using a user interface. This essentially rules out beacon detection.
Bluetooth scanning APIs are still in draft form here.
EDIT: The APIs mentioned by #zurfyx in the answer below allow you to scan for and connect to an advertised GATT service, but do not allow you to read the data in the advertisement. This is a critical distinction, as reading the data in the advertisement is the key capability required for actual bluetooth beacon detection. That capability is missing from that API. Without that capability, it is impossible to detect a beacon, it is only possible to connect to a BLE device that might be an Eddystone or other service advertisement-based beacon.
UPDATE July 2020: Safari will not be getting any WebBluetooth APIs at all due to privacy concerns, according to a June 2020 announcement by Apple This makes Bluetooth scanning impossible on iOS we apps for the foreseeable future.
As of July 2020, Chrome does not support scanning arbitrary advertisements. See status here: https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md
Disclaimer: I wrote eddystone-web-bluetooth (a library which makes it easy to read and write to an Eddystone device). github#eddystone-web-bluetooth npm#eddystone-web-bluetooth
It is possible to scan for Bluetooth devices by using the Web Bluetooth API (currently supported only by Chrome).
By using Bluetooth GATT service, you can connect to Eddystone devices and send/receive data by communicating following their public specifications (which are basically a list of request codes, and the format in which to send and expect their responses).
These services include information such as:
URL
Advertising interval
Lock state
and more
By using the Bluetooth standard information you can get to know the most generic device information, such as its id and name:
navigator.bluetooth.requestDevice
#beaufortfrancois wrote the probably first Eddystone Web Bluetooth configuration code (source code / demo), so it is probably worth a read if you want to dig more into this. I learned a lot from it.